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.

Java Think versus VB Think

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.

Design-Time Metadata

A key part of the new beans extension can be understood best with a comparison. Bean authors will be familiar with BeanInfo, a bean companion class that tools discover and associate with a bean class at runtime. Part of the JavaBeans specifications from the beginning, BeanInfo contains static metadata about a bean's class.

The new proposed class, DesignInfo, defines dynamic behavior information about a bean instance. Because DesignInfo is discovered at runtime, or design time, existing beans require no changes to benefit from this new functionality. According to Nuxoll, understanding the difference between design-time configuration and static metadata is key to making Java a friendlier developer environment.

JSR 273 sets out to offer several design-time enhancements to the bean experience. First among them is the ability to define an initial setup for a component when that component is created. For instance, when you drag a component representing a database table to a design canvas, you will be able to define a data model for that table, the columns you wish to populate, and even allow you to proceed to populate that table. The table component's DesignBean will provide hooks for that functionality.

The current JavaBeans specifications define a few static ways to relate beans to one another. JSR 273 offers more dynamic abilities to link beans via the linkBean() method on DesignInfo. That will allow a bean to dynamically interact with mouse events, or respond to drag and drop in a customized way. As a component author, you will even be able to define hot areas on the bean's visual representation for special design-time behavior.

In addition, JSR 273 adds a context item to a bean instance. Such context can include, for instance, a list of common actions a developer would typically perform on that bean. That list could then be displayed by, say, right-clicking on the bean's icon. Nuxoll pointed out such possibilities have been part of VB and .NET for a long time, but were not available for Java components before.

A component author will also be able to specify runtime annotations for a bean. For markup-type components, such as JSF beans, that could mean rendering hints, whereas for components that need to paint on the screen, that often means custom painting. For instance, once you've associated that table with a data source, the design-time representation of that table on the design canvas would be able to display a database icon to indicate the availability of the data source.

In addition to property editors and customizers, all these additions to the JavaBeans API are designed to provide access to live bean proxies that facilitate design-time interaction with beans. While IDEs already define such proxies, says Nuxoll, each IDE vendor provides its own custom mechanism for how such proxies manipulate a bean at design time, and how the IDE provides design-time customization information bean proxies. JSR 273 aims to standardize that interaction. As a result, a component vendor can rely on that standard to provide richer design-time options for her wares.

Will Java technology ever have the kind of component market that drives the VB and .NET universe? "The gap is still huge, but we're working to bridge that gap," says Nuxoll.

Get Involved

While no early draft of this JSR is available at the time of this writing, you can read the design-time API specs for Java Studio Creator. According to Nuxoll, the JSR's spec will likely be based on that source. Nuxoll invites anyone interested in contributing or commenting to contact him, or to join the JSR 273 expert group. Contact information is on the JSR 273 home page on jcp.org.

Resources

JSR 273, Design-Time API for JavaBeans:
http://jcp.org/en/jsr/detail?id=273

Design-Time API for Java Studio Creator:
http://developers.sun.com/prodtech/javatools/jscreator/reference/apis/index.html

A trial copy of Sun Java Studio Creator is available here:
http://developers.sun.com/prodtech/javatools/jscreator/index.jsp

Talk back!

Have an opinion? Readers have already posted 12 comments about this article. Why not add yours?

About the author

Frank Sommers is founder and President of Autospaces, a leader in on-demand computing solutions for the automotive sales and finance industries. Frank is also Editor-in-Chief of the Newsletter of the IEEE Task Force on Cluster Computing. He has written the Jiniology and Web services columns for Javaworld. He currently serves on the Jini Community's Technical Oversight Committee.