Sponsored Link •
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.
This month marks the ten-year anniversary of Java's first public release. Some four million developers later, the Java IDE market place has certainly come of age. While there are many high-quality IDEs currently on the market, many have bemoaned the lack of a Visual Basic-like tool that would allow a more component-oriented approach to Java development. That lacuna was mended last year with the release of Sun Java Studio Creator, a first fruit of Sun's Project Rave effort.
Project Rave's ambition is to lure VB developers into the Java universe by offering an IDE that lets one assemble complex applications by dragging and visually connecting components on a design canvas. If that sounds like the good ol' bean box, you are only partially right. Studio Creator lets you assemble entire J2EE apps from pre-existing components, and uses JavaServer Faces (JSF) to outfit those apps with a UI. While in capabilities and market share it is no VB (yet), the Java Studio Creator is a big step forward in making Java an easier environment to develop in.
Some of the technologies enabling that development ease may eventually be standardized via the newly accepted JSR 273, Design-Time API for JavaBeans. Recently approved to be developed through the JCP program, this JSR will benefit vendors of both IDEs and components. Indeed, it is that latter category, components, that's sorely missing in action compared with the VB landscape. According to Joe Nuxoll, Studio Creator's co-creator, the lack of a vibrant Java component market may partly be the result of a cultural gap, and partly due to Java lacking standard design-time mechanisms to work with components.
Artima recently spoke with Nuxoll, an architect at Sun's tools division, a former Borlander, a long-time tools guy, and currently the specification lead of JSR 273—Design-Time API for JavaBeans. Nuxoll pointed out a key difference between VB—and now .NET—and Java think. Suppose you're working to develop a new technology, such as voice recognition. The Java folks would approach that problem by defining a set of interfaces, classes, and configuration files, according to Nuxoll. VB and .NET developers, by contrast, would solve that task by asking instead what set of visual components could be combined together to provide the desired functionality. In other words, in the Java world, the solutions are focused on class libraries, not component libraries. .NET developers, on the other hand, think of solving problems in terms of components, rather than class libraries and configuration files.
One of Nuxoll's jobs at Sun, and as JSR 273 lead, is to push the Java platform more towards components. That requires a bit of technical work because component-centered thinking requires excellent component support in IDEs. Components would have to be configured at design time in a much more sophisticated way than what is currently possible with JavaBeans, says Nuxoll. Hence the need to extend JavaBeans to include design-time functionality that component authors can leverage in visual environments to make components easier to use.
It turns out much of the hard technical work was already put forth in architecting Studio Creator. Nuxoll mentioned that during that architecture phase, the Sun team consulted with many tool vendors and defined Creator's component-configuration API with the future in mind. Indeed, says Nuxoll, that configuration API is de-coupled from Sun's product to such a degree that it can form the basis for JSR 273. Other tool vendors seem to agree, since the JSR is supported by Borland, Oracle, and BEA, and additional vendors might join the expert group as the work on the JSR gets under way.