Slashdot Mirror
Sun Plans VB-Like Tools For Java
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"?"
About four years too late, but hey.
Dave
I write a blog now, you should be afraid.
Sun apparently is trying to create a more VB-like experience for developer.
:)
OK, is this a deliberate attempt to erase any positive feelings that anyone has ever had for Sun or Java?
Well as a VB developer (don't hit me please), I find that Java seems just a bit unapproachable. Now that I moved to VB.NET, I don't feel as dumb as I used to when it comes to OOP, so I think I could actually get into Java with 4 on the floor. Having a set of tools that make this transition easier for us VB developers would be beneficial for the Java market.
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.
I work at a Java shop. At a government agency actually. There are a few people to whom anything that looks like C++ is too difficult for them. There are many developers who like java but there are those who would prefer something like VB.
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
If this follows Sun's other attempts at engineering in the Java API's it should work pretty well.
.Net and C# for developing business systems, but the tools need to be on the same level. I guess you could say 'It's the tools, stupid!'. Maybe Sun will realize that decent development tools are the crack that MS has used to hook tons of developers and if equivilent tools were available to new Java developers (and experienced ones who hate tedium), the rate of adoption would pick up.
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
Arrogance is Confidence which lacks integrity. -- me
I'm not a Java guy but I'm a strong believer in rapid development tools like VB. The why is simple. Often times applications are going to be used by a very small number of people or more generally for a small number of man hours over a larger number of people (say 10 people to run for 5 weeks and then never touch again). The cost of development can be a serious issue.
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?
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.
BEA is already pursuing this.
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
... does this theory of mine make sense?
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?
-pyrrho
A VB-like experience was the whole motivation behind the introduction of JavaBeans back in '97. A JavaBean-compliant widget was supposed to be readily usable by GUI builders, a la the VB IDE.
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.
We are working on tools that the historic visual developers will find very attractive. They will be all written in Java.
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 to be ported to GNU/Linux.
The US Army: promoting democracy through unquestioned obedience
Puh-leaze! Apparently you don't read those lists very often, the idiots are already out there. Lots of kiddos looking for people to do their CS homework for them.
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.
Does the world really need Yet Another RAD Tool? I can't speak fully for the Swing/Awt world, but the medium-sized Java projects I've been on was developed with textpad and apache ant.
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.