JBuilder Doesnt Revolutionize

Its easy to offer a single vision of how things ought to be; its harder to build a coalition of compatibility.

Borland Software Corp.s JBuilder 8 shows the strain of that competitive burden, which faces the Java development community as it confronts the monolith of Microsoft Corp.s .Net platform. Released in November, JBuilder 8 offers significant incremental improvements over Version 7, which eWeek Labs reviewed in June (see www.eweek.com/links). Even so, Version 8 inspired less enthusiasm during our review than any previous update to the product thats been our favorite Java tool since its first release in the summer of 1997.

Borland has correctly focused on the need to assimilate existing Java efforts into JBuilders framework: It streamlines creation of JBuilder projects from raw code or Visual Café. The new JBuilder makes one pay for its convenience, though, by being shockingly resource-intensive. Its the first tool weve used that feels short of breath in what used to be a generous 256MB of memory.

Even those whove been spoiled by the high integration of a Smalltalk development system will be pleased with JBuilders ease of access to, for example, all the references to a given method or to the contents of a given data field in the instances of a class. As development tools offer more of this kind of information, the task of navigating the resulting haystack in search of relevant needles becomes a challenge. JBuilder 8s consistent use of tree-structured views makes it easy to learn ones way around.

Speaking of Smalltalk, anyone whos ever used that category-defining object-oriented language will appreciate the Java Development Kit 1.4 Hot Swap technology, used in JBuilder 8 to enable on-the-fly modification, re-compilation and continued debugging in the manner of an interpreted environment. As with Smalltalk, the result offers the same power and risk as doing brain surgery on oneself, but its nice to have the option.

Smalltalkers will also recognize the MVC (model-view-controller) design pattern for interactive applications. JBuilder 8 introduces Borland tools based on the Apache Jakarta Projects MVC framework, Struts. (Go to jakarta.apache.org/struts for more information.)

JBuilder 8 is the first tool set weve seen whose hardware recommendation calls for 512MB of RAM, with 256MB the grudging minimum allowed. We believe that developers will find those resources well used, though, and that any false economy in hardware will quickly be offset by painful delays on projects of any substantial size.

Some of the touted productivity aids in JBuilder 8 sounded much more useful than they actually were in tests. For example, the source code editors customizable re-formatting, promoted as enabling a uniform style for line breaks and other conventions, fell short of our hope that it would turn arbitrarily ugly code into something we could easily read. Theres considerable room for improvement in this potentially attractive feature.

Web services tools were available a la carte to developers adopting JBuilder 7, in the form of a downloadable tool kit thats now included in the package with Version 8. Borland offers ecumenical support of Borland Enterprise Server, BEA Systems Inc.s WebLogic Server, IBMs WebSphere, Sun Microsystems Inc.s Sun Open Net Environment and Sybase Inc.s Enterprise Application Server in the JBuilder 8 package—with the promise of additional application server support code on the companys developer network site at bdn.borland.com.

Streamlined Web application wizards in JBuilder 8 offer automated assistance in building with Apaches Cocoon XML publishing framework (more information is at xml.apache.org/cocoon) as well as with Struts. Regardless of the framework used, though, the exemplary Unified Modeling Language integration that we praised in Version 7 will continue to aid developers in finding their way through the more complex projects that theyll take on with JBuilder 8.