Java and Visual Basic have always resided on opposite corners of the developer universe. New technology in the works through the Java Community Process now aims to bring VB-like ease to Java development. This article reviews JSR 273, the Design-Time API for JavaBeans, and offers a few hints of where Java IDE tools may be heading.

http://www.artima.com/articles/designtime.html

What do you think of the Design-Time API described in the article, and where do you believe Java developer tools are headed?

How do you write unit tests for applications written using a VB-style IDE? If there aren't any tests, this sounds like a step backwards.

> How do you write unit tests for applications written using
> a VB-style IDE? If there aren't any tests, this sounds
> like a step backwards.

That's an interesting question. I think the components themselves would usually be written as classes, and as a paying customer of a component, I'd expect the components to be well-tested and robust. I would then tie components together graphically, in VB style, viewing property lists and setting them, etc. Other parts of my app that are written as classes I could test in the traditional way. When I write an event handler, though, I'm curious how I would test that.

I'm not sure writing tests is something VB programmers often concern themselves with. I'm also not sure to what extent automated tests matter for the kinds of applications VB is used for. Plain old testing may suffice. My perception is that VB is often used for internal apps that have a small number of users. VB is so hugely popular, that I'm sure it's used in lots of ways. But the smaller enterprise app, used by dozens of people in one department and written by folks who don't necessarily think of themselves computer scientists, is I believe the main market project Rave is trying to target.

The event handler code that is typed in dialog boxes in VB style does end up in a class, so in theory it is testable in the usual way. But I suspect most VB programmers would see that as more trouble than its worth.

> How do you write unit tests for applications written using
> a VB-style IDE? If there aren't any tests, this sounds
> like a step backwards.


I think components of the kind this JSR talks about are just plain old Java classes + design-time metadata that allows their manipulation at development time. That manipulation, in turn, generates plain old Java code in the background. The tools help write that code in response to visual gestures performed by a developers on a design canvas. For instance, you can indicate that you want to link beans together, etc. That rich design-time manipulation ability makes these classes components.

The difference that Joe Nuxoll hints at is that we Java kinds tend to just tuck a few JAR files into a directory, add those JARs into our classpath, fire up our editor, and proceed to write code that interacts with the classes inside those libraries.

A VB person, on the other hand, would stick a component into a visual tool's component palette. The component itself might come in a JAR file, of course. But, instead of firing up an editor and writing code to manipulate the classes inside those library files, he fires up a design canvas, drags design-time representations of those components onto it, and assembles applications via visual gestures, i.e., dragging, dropping, etc. Then, on occasion, he might write small snippets of code here and there to enchance the basic interaction model defined via the visual gestures. The end result in both cases, though, is just plain old code that can be tested.

Oh look - programming tools for non-programmers! Again. Great.

Clue - non programmers DON'T PROGRAM.

OK, so maybe non-programmers is too harsh. Lets say that they are really just algorithmically challenged. So now we have a tool that automates construction of bad applications. Nifty. I can hardly wait to use some of these wonder-apps.

Except I don't think we'll have to worry about it for awhile. JavaBeans was a resounding failure. BeanBox was never more than a curiosity and NextStep's Interface Builder remains a uniquely powerful curiosity that has still yet to be equaled because the Java people still haven't figured out Blanchard's Law and think code generation is a good way to build an application.

Capping it all off is the static nature of Java which makes dynamic developer at least an order of magnitude than it ought to be.

I'm not holding my breath here.

If your memory goes back to the bad old days of Fido Net and 300 baud modem you might remember the state of Windows shareware before Visual Basic and after Visual Basic.

Before VB you had to program in C or C++. The average quality of the programs was much higher than those produced after VB was released to the world. It got so bad that I didn't even try downloading any program that required vbrun.dll.

I supect similar things from this.

> If your memory goes back to the bad old days...
>
> I supect similar things from this.

And once again the world will be all the better for it.

In the 'bad old days' programs were essentially written by highty trained specialists who produced highly specialised apllications for a highly specialised audience. VB (and other languages, tools and hardware) opened up this closed world. Anything that does this is to be welcomed. Now, it may fail or it may succeed. Who knows? Meanwile, to stand on the sidelines predicting doom and gloom, even before the release has happened, like some latter-day Eeyore is surely a pointless and miserable place to be.

In any case I would contend your assertion that the quality of software has declined. Assuming that 90% of everything, including software, is rubbish (and that 90% of the rest isn't much better); it could be argued that all that has happened is that the volumes have increased. (However, having spent 4 hours yesterday failing to get some new software - Fitnesse - to work; maybe you're right.)

Vince.

> Oh look - programming tools for non-programmers! Again.
> Great.
>
These tools are not exclusively for non-programmers. I only tried VB once, but did do some work with Delphi and quite liked it. And I'm a "programmer." I recently saw a demo of Sun's Java Studio Creator app, and was impressed with the speed. They could make a little web app much faster than the way we do them at Artima. Although I don't that kind of tool is not appropriate for what we're doing most of the time here, it seems a good fit for a large number of problems. So I think that tools like VB can help programmers move faster and are very appropriate in certain tasks.

The other thing that this Design Time API JSR reminded me of is more dynamic languages like Python. Such languages tend to help programmers move faster, and are easier to learn than Java or C++. They also focus more on building programs by interacting with objects, not classes, just like VB and Studio Creator.

> Clue - non programmers DON'T PROGRAM.
>
> OK, so maybe non-programmers is too harsh. Lets say that
> they are really just algorithmically challenged. So now
> we have a tool that automates construction of bad
> applications. Nifty. I can hardly wait to use some of
> these wonder-apps.
>
I think there are a lot of people who aren't programmers but who could benefit from doing some programming: scientists, accountants, engineers--lots of people. And I don't think it is a bad thing to try and figure out how to make programming accessible to them.

VB programmers have a bad reputation in the programming community. I spent about 5 years programming MS Visual C++, and in those days we all turned our noses up at the VB programmers. They were considered not as smart as C++ programmers. We felt they were programming in VB because they couldn't handle C++.

I didn't really spend time in the VB world so I don't really know the culture, but I don't see why using a tool like VB is inherently going to produce bad programs. Maybe what's missing is a set of best practices for VB programming that is part of the VB culture. I'm not sure what is valued in that culture. It does make sense to me that tools like VB could enable otherwise incompetent programmers able to produce something that kind of works on the surface, but is really crap and unusable underneath. But I doubt that's the main use case of VB, because otherwise wouldn't those 4 million or however many VB programmers lose their jobs?

I'm also curious what the demographics actually are for VB. Who are these programmers, and what are they actually building and deploying. I always imagined most of them building small enterprise apps used by 20 to 80 people, things that aren't mission critical. Does anyone know what the demographics are? My understanding is that Sun wanted to target these programmers with project Rave, and I believe Java Studio Creator is part of that strategy. Who are these people, and what are they building?

> The other thing that this Design Time API JSR reminded me
> of is more dynamic languages like Python. Such languages
> tend to help programmers move faster, and are easier to
> learn than Java or C++.

This I buy. But to make this work, you need dynamic languages. Java acts more like a static language.

> I think there are a lot of people who aren't programmers
> but who could benefit from doing some programming:

Sure, I'm a recovering stack head. But they are fundamentally different sets with completely different concerns. You're not going to make Java accessible by bolting on a bunch of superfluous descriptors.

> They were considered not as smart as C++
> programmers. We felt they were programming in VB because
> they couldn't handle C++.

Yes, I feel similarly about Java programmers when interviewing potential hires. They can't analyze algorithms, they can't calculate sizes. They don't know when memory allocations are potentially too expensive. They make poor design decisions when they make them at all (usually they waste resources trying to ape some "pattern of the month").

Oh, boy. What nonsense. They teach algorithms in Java these days. If someone can earn a living programming in VB or simple Java, the more power to them. Let the market decide.


>
> > They were considered not as smart as C++
> > programmers. We felt they were programming in VB
> because
> > they couldn't handle C++.
>
> Yes, I feel similarly about Java programmers when
> interviewing potential hires. They can't analyze
> algorithms, they can't calculate sizes. They don't know
> when memory allocations are potentially too expensive.
> They make poor design decisions when they make them at
> t all (usually they waste resources trying to ape some
> "pattern of the month").

> I'm also curious what the demographics actually are for
> VB. Who are these programmers, and what are they actually
> building and deploying. I always imagined most of them
> building small enterprise apps used by 20 to 80 people,
> things that aren't mission critical. Does anyone know what
> the demographics are? My understanding is that Sun wanted
> to target these programmers with project Rave, and I
> believe Java Studio Creator is part of that strategy. Who
> are these people, and what are they building?

Yoohoo! ** waves **

I spent 10 years programming VB applications that were deployed on trading floors in a rather large investment bank. The largest app supported 400 users globally and was deployed in many locations including New York, London, Tokyo, Houston, Sydney and Singapore. These were all mission-critical. Aside from stand-alone applications we developed many COM objects that could be plugged into Excel to perform diverse functions or perform connectivity to other systems.

I have also had in-depth exposure to Java, C and more recently .NET applications. IMHO a poor programmer will program poorly whatever the language - VB is a tool that performs a job and if used inappropriately of course you will get bad results.

Our VB was written using Rockford Lhotka's framework (http://www.lhotka.net) - so our applications always followed an MVC type pattern.

In a front-office, trading floor environment, we need to deliver applications quickly and efficiently. This is one area in particular where you will see a lot of VB (and VBA) applications. I don't believe Rave will ever supersede these apps because they require COM and/or Office interopability - what we will see is a move towards .NET, and this trend will grow as .NET becomes more prevalent in Office.

My two cents....

Building a complex GUI faster has NOTHING to do with building the GUI up-front and adding "scriptlets" here and there.

When I built my last Java application (about 2 years ago), building a decent graphical interface took me about 20-40% of the development time. That's huge! Truth is...I was expected to rebuild in java a former VB app. Put it on solid ground:-) Therefore I'm glad to find out that there's a chance of making GUI development less tedious.

Will the beans be able to interact with one another - obviously controlled by the DT user?

For instance the user creates a bean of type A, a, then of type B, b. Now A has a reference to B. Will the proposed API allow the DT tool for instance to drag b into a, thus setting the reference?

Usually DT tools allow this sort of thing but only with visual components - so you can drag a button inside a panel.

Basically, will there be much support for non-visual JavaBeans?