We test the top 6 Java visual IDEs

The latest pack of Java tools delivers full JDK 1.1 support, raises the bar on performance and features

1 2 3 4 5 6 Page 2
Page 2 of 6

JBuilder, VisualAge, Cosmo Code, SuperCede, and Visual Café all allow you to select multiple objects to copy or cut. Only JBuilder, VisualAge, and Visual Café let you change properties on multiple objects. Although VisualAge does not let you change layout constraints on multiple objects in this manner, it does have a number of tools to help you layout and resize multiple objects.

The visual programming paradigm

Full-fledged visual programming can involve more than what most Visual IDEs offer. Beyond the fundamental capability to visually place objects, the tools we've reviewed vary greatly in their visual programming features. To help you appreciate these distinctions -- and decide how important such distinctions are to you -- let's review what visual programming means.

Next Computer, in its NextStep development tools, helped popularize a key tenet of visual programming: the idea that a good deal of programming tasks can be made simpler by doing them graphically. Visual programming deals effectively with not only the placement of visual components, but the connections between them, as well as the connections between non-visual components.

Because there isn't a way to effectively express all programming idioms, many tools choose not to support much of this aspect of visual programming. JBuilder, SuperCede, and Java WorkShop do not allow much visual programming, although Java Studio (Sun's Java app builder for non-programmers) does. Sun plans to include and more tightly integrate Visual Studio with the next release of Java WorkShop. This should result in a powerful tool for both experienced programmers and non-programmers.

Cosmo Code, Visual Café, and VisualAge for Java all support visual programming at various levels. Also, Sun's Java Studio provides some visual programming capabilities that can work with beans. Although Java Studio was not included in the last JavaWorld comparative review of integrated development environments, it was described and reviewed in separate JavaWorld articles. (For details about Java Studio, see Resources below.) Java Studio 1.0 is a noble first attempt to enable visual programming, but it currently is a separate tool from Java WorkShop and it's rather limited compared to IBM's support for visual programming. This is because Studio uses specially defined connections of a bean, whereas IBM supports all interfaces of each bean.

Raising the "bar" of visual programming

Cosmo Code, VisualAge for Java, and Visual Café (and Java Studio -- but not Java WorkShop itself) also are unique among reviewed tools in that they can define interactions with non-visual components. The best visual programming tools set themselves apart from the others in terms of flexibility. This includes the tools' ability to edit interactions that already exist, use data from more than one object to go into another object, and deal with complex data*. For example, with any of these four tools that can define interactions with non-visual components, you can make a button-push cause a value from a text field to go into a list field. But only VisualAge for Java lets you graphically use the list value as a parameter to a (non-graphical) bean's method, to come back with values with which to populate the list field.

You need to decide how important visual wiring and interaction are for you. For the most part, these features are useful only when you need to call one method on a particular class. They don't help much, for example, when you want to have many buttons call the same method, or when you want an action on one object to take data from another object and act upon a third object. Even for these more complex interactions, however, the visual-programming capability does give you a head start, providing code that you can manually tweak.

Native compilation

Applications written in Java (or other languages) can be fully compiled (to native code) to improve performance, feature richness, quality, and security. We saw this trend happen with Visual Basic, and after years of delay it's finally starting to happen with Perl.

Applications should be compiled when they:

  • Require higher performance than the Java VM and JITs can deliver. Full Java compilers, such as those offered by Symantec and SuperCede, typically provide performance levels not possible with interpreters or JITs. (The other four tools reviewed lack native compilers.)

  • Contain proprietary content, and therefore need better protection from reverse engineering. Java is easy to decompile to source. Products that obfuscate code do not fully protect against such decompilation, and using obfuscators has a variety of drawbacks. These drawbacks include the extra step you must go through in your production process, the effort you must go through to verify that your obfuscator doesn't do any harm, and the fact that debuggers won't work properly on production code which has been obfuscated.

  • Would not benefit from, and might even cause harm to, the "compile once, run everywhere" model. This includes critical software, such as financial applications, machine control functions, wireless communications, and security software, that must be tested before being allowed to run on unknown platforms. Distributing software as bytecodes indicates your code is caveat emptor code -- "It should run on your platform, but I haven't verified it." Designers of every program needs to ask themselves, Do I want this code running on a platform that is substantially different than any it has been tested on? and Do I trust that the program will behave properly, even if the JDK or third-party class libraries are updated? If you answer no to either question, you may wish to consider native-compiled versions for each platform as one way to ensure your code won't be run where it shouldn't.

  • Must operate in severe target memory constraints. The full JDK 1.1 class libraries weigh in at more than 10 megabytes, not including the underlying support from the OS (another 1 to 10 megabytes) or the browser (which typically may require 8 or more megabytes of RAM when running on a standard desktop computer). Sun indicates that the PersonalJava class libraries will be only 2 megabytes, but many applications will not run because, as a subset of Java, PersonalJava will lack some libraries. In addition to PersonalJava, applications may be written for Java Card, EmbeddedJava, or the full JDK. The only way to ensure that bytecode applications will run is to have support for the full JDK. Compiled applications can include the needed libraries, or you can use the Symantec runtime library for compiled Java, which is only about 2.5 megabytes and supports all JDK 1.1 classes and methods.

Symantec has managed to make the binary version of the class libraries much smaller than the normal JDK. Instead of needing a 9-megabyte classes.zip file, a compiled Java application needs only those dynamic load libraries (DLLs) that actually are used in the application. (The JDK's full set of DLLs accounts for about 4 of its 9 megabytes.)

In the June review, we pointed out SuperCede's ability to compile Java to a native executable. Since then, Visual Café has added this feature. Cosmo Code has some compilation ability with its Java to MIPS translator. Others vendors are considering native compilation for future releases of their products.

Major features

Major featuresBorland JBuilder 1.0IBM VisualAge for Java 1.0 ProCosmo Software Cosmo Code 2.5 ProfessionalSun Java WorkShop 2.0SuperCede Inc. SuperCede 2.0 ProfessionalSymantec Visual Café Pro Dev Edition 2.1
CM, test, and profiling toolsNoNo (Enterprise edition has CM)NoCM interface, built-in profiler and basic test frameworkIntegrates with Versions 2.0 and VTuneTesting, CM, VTune
Visual programming (interactions)No. Does have non-graphical Interaction Wizard.Best: Can visually create/edit interactions between all components. Can selectively show interactions.Better: Can visually create/edit interactions between all components.No. Studio product has limited visual interaction, even with non-visual components.No.Good: Can visually create (but not edit or visually show) interactions between all components.
Printed documentationGood. Programmer's Guide includes tutorials (210+ pages), task-oriented User's Guide (220+ pages)Good. User's Guide (200+ pages), Programmers' Guide (190+ pages)Inadequate. Getting Started booklet (17 pages)Light, tutorial-level: Exploring Java WorkShop (108 pages)Comprehensive User's Guide (275 pages) and a tutorial-oriented First Look (70 pages)Extensive, task-oriented (400+ pages) User's Guide, Getting Started (200+ pages) and Visual Page (140+ pages) docs also well done.
Database supportYesOnly in EnterpriseYesLimited, more in EnterpriseData aware controls for any JDBC sourceLimited, more in Enterprise
Online documentationVery good on Borland's added classes, but not context-sensitiveNot context sensitive. Basic help & MindQ tutorialsVery basicYes, but slowBasic help & MindQ tutorialsBasic
HTML Page generationYesYesYesYesYesYes, also includes Visual Page
Reverse engineeringYesNoNoNoNoYes
Ability to add your own objects to PaletteYesYesYesYesYes, beans or ActiveXYes
ActiveX supportedNoIn Web-Runner productNoNoYesNo
Additional Java class libsTop 100 beansNot included, but listed on WebRogue Wave JWidgets, JTools, JDBTools and JChartYesKL Group BWT, Shafir JCT, Stingray Objective Grid and Objective BlendYes
JDBC supportYesYesYesYesYesYes
Native methodsJNIJNIJNIJNIJNI, direct calling, C/C++ in sourceJNI

Tools that go both ways?

Each of these tools can generate code from the visual representation. At a minimum, this includes all the code required to place the object on the screen. For the purposes of this article, reverse engineering is the ability to go from a programmatic representation to a visual one. Of the tools reviewed, only Visual Café and JBuilder have this ability, and neither can handle all legal Java code.

Reverse engineering can be important for two reasons: better integration of manual programming, and importing Java projects. Let's cover those in more detail so that you can decide how important this feature is for you.

Integration of manual programming

There are bound to be some limits in the graphical programming paradigm. It might be a lack of support for all objects or methods, as was the case in Microsoft's Visual J++ 1.1 in our June 1997 review. Or, it may that you want your application to dynamically generate the screen, such as a graphics program, or generate database forms and reports on the fly.

In any case, there is a recognized need to go in and write code. Each tool provides some way for you to do manual programming without interfering with the code that it generates. Most tools have well-marked areas of code that the user must not edit. In addition to the designated sections that are OK to edit, you are completely free to edit any file that you add.

IBM VisualAge for Java has two positive aspects in this regard. First, it helps you build non-graphical code with its bean "maker" (basically a wizard). These beans then can be integrated and used in the visual programming paradigm. Second, most code that is off limits is relegated to separate files. The only small glitch is that VisualAge creates some files with headers stating that you cannot modify them, when in fact you can -- and often must -- do so.

Note also that although JBuilder and Visual Café allow reverse engineering, they cannot handle all manual changes successfully. JBuilder and Visual Café are most useful only when you create the code within the respective vendor's tool, or manually write the code using the respective tool's particular conventions. For example, neither tool can handle using a variable as a parameter to setColumns(). If there are problems in parsing the code, neither tool is especially helpful in describing what you did that the tool didn't like: Visual Café's messages are not always meaningful, and JBuilder provides no messages at all. On Visual Café the visual representation isn't updated until you fix the code. On JBuilder, it may be updated incorrectly.

Importing Java projects

You probably have code that needs to be imported into your Java tool. This could be code you started creating with other tools, code you pulled off of the Internet, or code from a project that you inherited. Any true Java IDE must have an easy way to add files to your project. In most cases, these files will have to remain as part of the program that you can edit only manually; you can't visually maintain such pre-existing Java code.

What is an "open architecture"?

Each of these IDE tools is a framework from which developers design, test, debug, and deploy their code. In order to make this process effective, each of these tools (designer, debugger, etc.) in the framework needs to be good. A weak tool is a weak link in the chain.

If the framework doesn't include the very best of tools for all steps in the process, it can still be a good framework -- as long as it allows you to use your own alternative tools. Borland C++ has offered an open architecture since at least 1992. This makes it easy to plug in your own tools for translating files, such as code or test generators. Of the tools in this review, none are completely open architectures. Borland and IBM, however, both offer APIs to partners who wish to create add-in tools, and the other IDEs can probably make similar arrangements.

1 2 3 4 5 6 Page 2
Page 2 of 6