eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
NetBeans IDE 5.0 is a substantial step toward bringing open-source, multiplatform Java tools up to the standard of toolmaking that is arguably defined by Microsofts Windows-only Visual Studio.
Click here to read the full review of NetBeans 5.0.
2
NetBeans IDE 5.0 is a substantial step toward bringing open-source, multiplatform Java tools up to the standard of toolmaking that is arguably defined by Microsofts Windows-only Visual Studio.
A major update to the NetBeans open-source IDE (integrated development environment) and application platform, Version 5.0 became generally available on Feb. 1 at www.netbeans.org. eWEEK Labs tested the general release code on Windows XP and Mac OS X workstations; the IDE is also available for Linux and Solaris.
Competing Java tools—notably open-source alternative Eclipse—will be challenged by NetBeans 5.0s improvements in the key area of building a GUI for a client-side applet or application. Many developers acknowledge GUI design and construction as a relative strength of NetBeans; the 5.0 update further widens that gap with a new GUI editor, formerly known by the project name Matisse, that gives excellent feedback during design and enables convenient testing.
Since NetBeans help text and documentation variously refer to this visual tool as the Form Editor or the GUI Builder, the name Matisse will probably persist for some time. During our Windows and Mac OS X workouts, we quickly grew accustomed to Matisses subtle but clear alignment indicators, which appear whenever a GUI component approaches a likely location such as left-edge alignment with another control.
Theres still room for improvement in this alignment-guide feature: Having seen this kind of thing done in several computer-aided drafting tools, wed be glad to get, for example, convenient guidance for centering components either vertically or horizontally with respect to one another.
Even so, its increasingly important that Java applications not only run correctly but also look right on a variety of devices with differing displays. Matisse greatly eases the design of a graphical interface whose components arrangement and size adjust automatically, whether to suit varying device constraints or in response to actions such as resizing windows. Selecting component-anchoring options on a right-click menu gave us immediate feedback through the on-screen alignment markers.
Another right-click menu offered us the opportunity to run, with full interaction, any element of our work—without requiring that the entire project be complete or even that it be internally consistent. We found this a very comfortable environment for rapidly converging on the appearance and behavior that we preferred.
Developers will probably not object to Matisses demand for use of the popular Swing user interface technology—and the need to have the Swing Layout Extensions library available to deployed code—as the price of taking advantage of this productive and (mostly) intuitive tool. That “mostly” qualifier comes from the occasional excess of helpfulness when Matisse tried to maintain what it thought to be our intended relationships among component positions. The tool sometimes rearranged other components, in what we sometimes found to be unattractive ways, when we changed a components location. Fortunately, any such collateral damage could be reversed with the Undo command. (In general, NetBeans 5.0s multilevel Undo facilities were entirely adequate.)
To pick one nit, we did find that the process of GUI construction using NetBeans 5.0 on Mac OS X could get a little ugly if we dragged a control from the palette to the form, rather than clicking on the palette to select a control type and clicking on the form to drop an instance of that control. If we dragged the control, the unnecessarily heavy outline of the label for that control came along for the ride until we dropped the control in place. Developers who find this an annoying distraction will doubtless quickly learn not to do it that way. The GUI construction process on Windows XP was both smoother and better-looking.
We encountered only this and other comparably minor differences between the NetBeans 5.0 implementations for the Windows and Mac platforms. Overall, were confident that multiplatform Java application and applet developers will find the 5.0 version an attractive option. Even so, those little inconsistencies—though truly minor—are a reminder that “write once, run anywhere” is a Zenos Paradox sort of destination that never seems to be actually reached.
Visual convenience has to manifest itself at some point in actual code: On both of our test platforms, we noted with foreboding that the NetBeans 5.0 source code view does not initially display the code being generated by the visual editor, showing instead a comment warning the developer not to modify that code and collapsing the code itself to a label using the source editors outlining facilities. Weve always considered such aloofness a red flag; we saw another warning in that this code could be expanded and read, but not modified, from within the NetBeans editor.
Of course, we promptly opened an external editor to see what would happen if we mulishly insisted on altering the code directly. The answer is that the visual form designer, upon our reopening that project element, ignored our source code changes until we used the visual tools to make other changes affecting the same code regions—at which point our changes were blown away by newly generated instructions. Thats not the kind of multilateral cooperation among interacting tools that weve grown to expect from experience with Borland Softwares JBuilder and Oracles JDeveloper 10g, to name two examples of the current state of the art. The latter of these, we must note, is fee-free, just like NetBeans.
We have a certain reverence for the idea that the source code is the definitive text of a program, with all other associated files being bookkeeping tools that development environments should regenerate from altered code as needed. We believe that configuration management systems, difference-patching tools, and testing and quality control systems all should be able to look at the source—and, as necessary, modify the source—as part of any given development shops idiosyncratic workflow. NetBeans doesnt observe that doctrine: If external tools want to alter a NetBeans-built GUI, theyll have to do it by altering the XML file that the visual editor uses to represent component states and relationships.
We found that we could readily alter GUI component characteristics by revising that XML description, which is, at least, readily human-readable. Developers may even find it a strength to have the GUI look and feel represented in that parametric manner rather than being buried in other program logic.
When we revised the XML .form file, we immediately saw the effects in the visual editors representation of the GUI upon reopening that element of the project in NetBeans—but the source code was not brought into consistency with those changes until we made further alterations using the visual tools. That was not, it seemed to us, the best way to do things. Time stamps, for example, could be used to trigger an automatic update of the Java code to reflect the externally edited XML description. Weve seen several tool sets with more fully synchronized round-trip interaction between visual and source code editors in several other development tools. Overall, though, the NetBeans 5.0 visual tools are reasonably robust in their handling of outside interference.
We dont want to give short shrift to the extensive improvements in the NetBeans source code editor. In the manner of the best such tools, it now gives immediate warning of errors that would make code unable to compile, without waiting (like some) for the cursor to leave the offending line; pop-up tool tips indicate the suspected problem. Drag-and-drop movement and copying of code is another welcome improvement. Intelligent code templates are provided, and that collection can be modified or expanded.
New refactoring operations in NetBeans 5.0 include method, interface or superclass extraction. Were not always impressed by toolmakers lengthening lists of refactoring operations—wed rather see tools with an intuitive workflow that makes us more likely to write things the way that made the most sense the first time. When we discussed this question with an independent Java toolmaker, though, during the time that this review was in progress, he pointed out that Java is now old enough to have accumulated bodies of legacy code. Importing and refactoring old code assets is therefore an important part of what a Java developer has to be able to do. Point taken.
NetBeans 5.0s interactive speed and its general fidelity to platform user interface conventions should satisfy most developers. The minor behavior issues we found may soon be fixed; in the meantime, they wont bother most developers.
NetBeans 5.0 proves that Java-based tools can no longer be quickly distinguished from native applications: The result is nothing but good news for developers, who consequently enjoy growing ease of multiplatform development with tools that its hard to believe are free.
Next page: Evaluation Shortlist: Related Products.
Page 3
Evaluation Shortlist
Eclipse 3.1 Not just a free Java development environment but an ecosystem of plug-ins thats becoming the foundation of many commercial developer offerings (www.eclipse.org)
Oracles JDeveloper 10g 10.1.3 Lets developers tailor technology portfolios and deployment platforms to their needs; the platform is approachable but also second to none in capability and responsiveness (www.oracle.com/technology/products/jdev)
Technology Editor Peter Coffee can be reached at [email protected].
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.