Sun Plans VB-Like Tools For Java 52
CokoBWare writes "Sun apparently is trying to create a more VB-like experience for developer. This article from E-Week explains Sun's strategy in providing more VBesque tools for the Java developer. Can anyone say "Good luck Sun, and all the best"?"
Good idea. (Score:4, Insightful)
Dave
Re:Good idea. (Score:1)
Re:Good idea. (Score:2)
Re:Good idea. 4 year too late! (Score:1)
Yep, JAva most VB-like isn't that a kicker, after all the years of marketing hype on How JAva is "simple" language they come to this stunning realization..
Java is toast on the client side, and is only going to survive on the server thanks to the likes of IBM and such.. Sun is too busy saving its own *ss to worry about Java
Lets see how JAva plays out in the MicroDevices area.. if it dies, there you can sure bet java the number of Java programmers in the near future will be very few
VB-like? (Score:4, Funny)
OK, is this a deliberate attempt to erase any positive feelings that anyone has ever had for Sun or Java?
Re:VB-like? (Score:1)
This is about tools, not languages.
Tools should make your life easier, not harder. Unfortunately, many Java IDEs fail to take this concept quite far enough.
I've used NetBeans for several years, but having finished a few weeks of C# work, I am now missing the IDEs code folding.
Yes, I know that's available in JEdit [jedit.org].
In fact, that's part of the problem. Anything feature you could possibly want from a Java IDE is out there. Some in NetBeans [netbeans.org], some in Eclipse [eclipse.org], some in JEdit, some in Idea [intellij.com], (the list goe
Umm... why? (Score:1)
On a more serious note, I *really* don't understand the reasoning behind this decision on Sun's part. Any Java developers out there? What do you think about this?
Re:Umm... why? (Score:5, Interesting)
However, I think that most IT departments won't care a hill of beans to migrate all their existing code to another codebase because the tools are good. I think this will bring newer projects online with Java, and create a bit more competition in the desktop application market. Look back to what C was with Windows 3.1... Visual Basic made Windows programming easy. If this is any indication, then the new Java tools will give developers a leg-up on cross-platform development with Java.
Re:Umm... why? (Score:5, Informative)
Those developers who are proficient with java could make the objects that those that aren't as proficient could use to piece together for their customers in semi-programmer business-analyst fashion.
The business-analysts could stop writing crummy procedural based java code and use the simplified objects that other programmers make for them.
This is already possible to some extent with java as it is, but for some people that we have here (who should perhaps be let go of, but I'm not in charge) they find java to be too complicated. Anything to make it easier for these people will make java programming more accessible to people with less programming skills which could be better for everybody.
The
Re:Umm... why? (Score:5, Interesting)
Besides what's the real advantage of OO for GUIs if you aren't going to associated code objects with screen objects? And if you are going to do that why not just bind the code directly to the screen object? And if you are going to do that then why not just drag your object over and fill in a few boxes that ask questions?
Re:Umm... why? (Score:1)
Perhaps this new environment has now matured. If so, then there is no more reason for messing around with lower-level details. When the tehcnical infrastructure is the same for a large number of applications, then it is really time for a 4 GL.
Ten y
Re:Umm... why? (Score:5, Insightful)
Sure Java can do a nice flexible cross-platform (in theory, anyway) GUI front end, but even setting aside the performance issues of Swing, it generally takes a good bit more time to set up than a comparable VB interface.
Re:Hopefully.... (Score:1)
Re:Hopefully.... (Score:1)
LOL! Mod parent up!
It's about time (Score:5, Interesting)
While EJBs and other API's have been a great way to create reusable components with lots of enterprise class features, the idea of writing 5 different classes where a lot of the information is repetitive then editing a global XML file or two was rediculous. Hopefully they'll take the XDoclet approach and include the meta information used to generate this stuff from a single file.
It's really the same thing with 'JavaBeans', which I remember playing with in '97, the concept was really great but the extra maintenance on BeanInfo classes and such was a complete PITA.
It seems to me that Sun has created a lot of flexibility and interoperability in their development kits, but they have never addressed the management of the complexity that it creates. The best thing the commercial world came up with was systems that were quick hacks tied to their development tools (WebSphere anyone?). The Open Source world has offered stuff like XDoclet, which has totally simplified these tasks, but it seems no one at Sun has noticed.
I think Sun thought the commercial community would come up with the same level of engineering that they had in formulating their API's, now I think they realize that that market is still open and not only is it important to compete with the well-regarded tools MS puts out, but theres $$ to be made.
Java should totally stomp
Playing with Trolls (was: Re:It's about time) (Score:1, Flamebait)
Wrong
> They're a crummy abstraction of persistence
Wrong
> they mash application logic and object representation into one place
Wrong
> they're butt-slow
Wrong
> they're a bitch to write and maintain
Wrong
> Straight JDBC is much easier to work with
Wrong
> it's [JDBC] more flexible
Correct!
1/7 Sorry Try Again
Why Flaimbait? Re:Playing with Trolls (Score:2)
angel'o'sphere
Re:It's about time (Score:1)
It's really the same thing with 'JavaBeans', which I remember playing with in '97, the concept was really great but the extra maintenance on BeanInfo classes and such was a complete PITA.
[/quote]
If Sun gave you the right tools to manage those PITA BeanInfo classes instead of the by-hand work you most likely had to deal with, you probably would think that the idea behind separating design-time classes from run-time classes was pretty sweet. Same is probably true with EJBs as well (although construct
Re:It's about time (Score:2)
My best guess is that Sun thought the commercial tool developers would rise to the challenge. Just goes to show, that if you want something done right you have to do it yourself. The only tool that has addressed this in a portable, non-proprietary manner is XDoclet.
If you think the tools from Sun are better
Great! (Score:3, Funny)
[/sarcasm]
-psy
Re:Great! (Score:2)
-psy
Re:Great! (Score:4, Interesting)
I done C, C++, assembly, LISP, BASIC, PERL, Ada and Java. My hands-down favorite platform for developing large projects is Java. Despite the jibes of your hardcore hands-on-the metal guys and your ivory tower OO bigots, Java is a powerful, high productivity language.
The problem with it is that it's marketed "ease of use" brings a lot of subpar talent to the table under the guise of being able to code. It has also become the language of choice for many intro to programming classes. Hence, the unfavorable signal to noise ratio on the user boards.
Re:Great! (Score:1)
crap I sound like some yokel
Re:Great! (Score:2)
Re:Great! (Score:1)
Re:Great! (Score:2)
Talking of Java and toys....I'm working with embedded Java systems....the sort that could soon be in toys!!!
-psy
Re:Great! (Score:1)
Sun still following BEA (Score:4, Informative)
The last two versions of BEA's WebLogic Platform included WebLogic Workshop, which is a 'VB Like' tool to make developing web applications and web services much easier.
They even bought/hired a couple of ex-Microsoft guys to head the development effort.
Maybe that is why it looks so much like Visual Studio...
WebLogic Workshop [bea.com]
Java is VB by Sun.... (Score:3, Interesting)
Ok, done Sun's way might be the same as "done right", but then doing VB "right" is still a dubious achievment.
And look the whole industry is VM hungry (when considering all the other scripting engines), with Sun's blessing. I'm not sure the herd is right on this one.
And although Java is a resounding success on the server... has it made Sun any money?
JavaBeans anyone? (Score:4, Interesting)
Heck, the marketese even claimed that a JavaBean widget could be used in VB via a COM bridge.
Of course, none of this took off because Java never really caught on in the GUI world. Sure, you find Java GUIs now and again, but its main use has been server-side components.
I can't imagine Sun is going to dramatically change the Java language. That would be suicide. I would imagine they are going to investigate technologies that are able to hide its complexity under a pretty IDE and possibly engineer a renewed push for the JavaBeans architecture as a GUI framework.
Uh oh... (Score:5, Interesting)
I love Java on a fast machine, but most of the time I'm using a Pentium 2 with a 233MHz processor. I can't run jEdit, JBuilder or NetBeans on here because they're too damn slow!
They should write it in C/C++. Most Java applications that I've used run just fine on this "bitty box", but IDEs and text-editors slow to a crawl.
I guess what _I_ really need is JCreator [jcreator.com] to be ported to GNU/Linux.
Re:Uh oh... (Score:2)
How much RAM have you got? I run jEdit on a 300MHz mobile P2 (which is probably comparable to a 233, when uplugged) with 128Megs RAM, and jEdit runs like a charm. I actually use NetBeans, too, although I must agree that it is very slow, but still usable if I really need to.
If you don't run any of the slower plugins (like XML or SpeedJava), jEdit should run decently on your system
Re:Uh oh... (Score:2)
Gah, my fingers are faster than my brain, today. That should have been 1.4.1.
Re:Uh oh... (Score:2)
I work on a Pentium 200.
Java is fast enough on it to se no difference to Visual C++ in the IDE.
I have 128MB RAM, however and a SCSI system
angel'o'sphere
Tools emulation, not language emulation (Score:1)
Java-based RAD? Try Jython! (Score:2)
I've just gotten interested in Jython [jython.org], although I've been using Java and Python (separately) for quite a while. I can't believe I came to it this late. Imagine having the simplicity of an award-winning [fsf.org] dynamically-typed yet fully object-oriented scripting language at your finger tips for busting out scripts and relatively simple code, but with complete "native" access to Java libraries. (Quotes because it seems oxymoronic to use the word "native" to refer to Java.)
It's not quite the same as VB or even J
Something like this got me programming... (Score:1)
I'd learned some Basic around 10 years ago and I was quite intimidated when I found that the only programming languages usable for Mac OS X were Java and Objective-C. Then Apple came out with AppleScript Studio, which finally enabled me to write real programs with a GUI interface.
I'm now coming back around to learn C and Objective-C, but it's AppleScript Studio t
yart, anybody? (Score:3, Insightful)
One of the beautiful things about Java/C++/SmallTalk is that you just can't start coding in it. For most people, it takes time to learn. But when you do learn it, and learn it correctly, you'll start to think in terms of coding for the sake of the interface, instead of coding for the hell of it.
With RAD tools, it's super easy to start coding what's in your head at the time being, making up classes and methods as you go. Why not global variables? You may start out coding for a prototype. This prototype doesn't get redesigned, let alone refactored for the actual implementation ('cause hey, we already have it 50% done). Then the next thing you know, you have bloatware. Then you leave your job, and some poor schmuck has to maintain your 'code'.
I didn't fully understand why you had to do so much in Swing to do so little until I read the GOF Patterns book. Most everything in the Swing API is an abstract pattern of some sort. When you create prototypes in Swing, you can't take a lot of things for granted. You actually have to think things through. And that, you just cannot rapidly do, initially.
But when you do understand the fundamentals, prototypes can be refactored or easily redesigned to fit the implementation. Of course, this means that the software engineer that develops the prototype must have some working knowledge of the API or framework. It means that you just can't have your average "learn XXXX in 24 hours" code monkey start the software process. It means RAD is not a tool, but a way of thinking. I professionally build prototypes for projects using textpad and ant. Much of which can be extended for the actual implementation.