A Powerful Tool, But LimitedBulletProof's JDesignerPro 3.5

• By Frank Flowers
• January 24, 2000

5 Outstanding      4 Very Good      3 Acceptable
2 Has Potential    1 Poor

ELVIS PRESLEY SANG, "I want you, I need you, I love you." The singer Meatloaf belted, "I want you, I need you...two out of three ain't bad." When it comes to a good Java Integrated Development Environment (IDE), I'd rather sing along with Elvis. Just because I use a Java IDE and need one for my job, doesn't necessarily mean that I've found the one I really love to use. So, I keep looking for something better.

Recently, I spent a few weeks using BulletProof's JDesignerPro (JDP) 3.5 on a business development project. The experience reminded me of a time when I was single and met this attractive girl. At first, I tried to overlook her little idiosyncrasies because I wanted the relationship to work. However, as I came to know her better, I realized that she needed professional help.

BulletProof says that JDP 3.5 runs on Windows, Linux, Solaris, HPUX, AIX, and Mac. I didn't test it on multiple platforms, but I think it should work because it's written in Java and only needs a Java VM to run. For my review, I installed the product on a Dell 266 MHz NT 4.0 workstation with Service Pack 6 and 256 MB RAM. It ran a little slower than I'd like, so I'd recommend using a faster machine. Everything installed fine and I finished all the tutorials. The tool looked good and it was easy to use, so I immediately began coding on a module for a development project. As I worked with the tool, I found a few surprises.

JDP comprises four parts: the Application Builder, the Deployment Manager, the Access Control System, and the Enterprise Server.

Application Builder
JDP's Application Builder is divided into client- and server-side. To its credit, JDP has a visual system to help with server-side development. If that's all you do, then you may want to check it out. Nevertheless, for most of us, if the client side doesn't work well, it's not going to be of much use. In my case, I was using it on a Java client-based project. Therefore, I'll focus on that.

JDP has a WYSIWYG layout manager with drag-and-drop capabilities. It's easy to use, but it's not too flexible. You can add fields and their labels to a new line, and you can append fields to a line with or without a label, but only in sequence. In other words, each field is added to the layout one at a time in order. However, to change the order or insert a new field, you must remove all fields that follow it on the page, add your new field, and then add all of the fields back the way they were. There's no absolute positioning, only relative positioning, and even that is possible only within certain constraints that make it difficult to modify. Here's where a casual look at JDP makes it seem great for development, but a more thorough look at long-term maintenance reveals its limitations.

The JDP Wizards exist on two levels. The product's seven General Wizards are designed to help you create a whole page made up of many parts. The Data Wizards allow you to create smaller objects on a page. A General Wizard allows you to create a screen consisting of a column layout, a search panel, a result list, and control buttons; to create the same thing with Data Wizards, you must use four Wizards. The result of either approach looks the same to the end-user, but to the developer, they are very different.

JDesignerPro's Wizards.

In addition, you must always use the Wizard you selected to maintain the program. Even though a General Wizard might create one screen made up of four components, you can't go back in with a Data Wizard for each component to make changes. The General Wizards are good for creating a simple screen, but they don't seem very useful for real programs that must be enhanced over time. When I used a General Wizard to build my first program with JDP and ran into problems and limitations, BulletProof technical support recommended that I get away from the General Wizards as soon as possible.

"It is also better," a BulletProof support tech told me, "if you get used to using the components in the Data group rather than the Wizard group, as your apps will be more flexible if you create each component yourself and link them using the Interaction Manager."

The source-code editor that comes with JDP is so primitive that it doesn't even have color-code formatting. Its only real feature is its code completion: When you type an object name followed by a dot ("someOjbect."), a right pane appears that lists the methods you can choose for that object. However, I don't like the way it works. The better editors have this feature occur right at the cursor, where you're typing. With JDP, you must use the mouse to click on the right pane because you can't just use the keyboard. There were times when I used the keyboard arrow keys to move across a line and found myself stuck at a dot where the tool stopped me. To make matters worse, there's no way to choose another editor and integrate it with the tool.

Likewise, there is no way to integrate a version control tool with JDesignerPro. For real development projects, version control is a necessity. Doing it outside of the tool is cumbersome.

JDP's Interaction Manager allows you to create interactions between objects. This feature was well done with the methods of all current components displayed. You choose an object, look at all of its methods, drag one to the component that is to interact with that object, and the tool guides you through the process of supplying the parameters. I found this very easy and intuitive, but I could not change the order of any interactions. You must delete the original interactions, add your new one, and then add the original ones. Again, the tool starts out well when you do something for the first time, but it doesn't seem to allow for changes.

The last part of the Application Builder is the Instance Manager. It's a visual tool that allows you to choose the constructor used to create a component. In other words, it puts you back into the Data Wizard that was used to create the component. In JDesignerPro's Layout View, containers that have a "WW" enclosed in the parenthesis beside them, are the ones that you can modify with the original Wizard that created it. For example, in a container with a panel made up of fields, if you click on one of those fields and then try to click on the Instance Manager button, you get a blank screen where the Wizard would normally be displayed. You must first select the higher-level container before clicking on the Instance Manager button. This is just something you have to get used to.

In the case of applets, JDP doesn't build a stand-alone applet for you. Instead, it builds a class file that is called by JDP's own applet program. This is not unusual in tools where session, state, and other information is maintained for you, such as in Sun's NetDynamics. It has its advantages and its drawbacks, but it's certainly not very portable to another development environment.

Deployment Manager
The Deployment Manager helps you deploy your class files to a local or remote machine that has JDP installed. You can edit the menu structure of the JDP instance you're deploying to, and it creates basic HTML for applets. It's a helpful utility because it shows that BulletProof recognizes that after you're done creating something useful, you also need to deploy it. I found it much easier to deploy a JDP applet than a Visual Café applet with all of its cumbersome steps.

Access Control System
JDP also includes what the company calls an Access Control System, which refers to the way a user gets access to a completed application. This feature allows you to specify whether a login is required. It allows you to set up and control user access so that each user is authorized for different parts of your system. And you can specify whether or not users need to log in to your system.

When someone logs into the JDP system running on the server, it displays only the menus and tabs that match the user's access level. This means that your application running under JDP has one User ID that it uses to connect to the database for your application. You're using JDP to manage the users' access. The application's end-users do not log into the database directly-which is good if that's how you want it to work, because you can save money by possibly using fewer user licenses. Instead of five users, each with their own license, you have one license for the User ID that JDP uses, and it manages the login of the five users. However, not long ago I worked on a project where the DBA insisted that each user for my application have his/her own Oracle User ID for better security and auditing. In this case, JDP's framework wouldn't help. I like that JDP considers user access control and realizes that I'm probably building a system, not just one stand-alone module. This may be its best unique feature, but for it to be useful, you must make sure it fits your database environment and your IT standards.

Enterprise Server
BulletProof's JDP 3.5 comes with an application server that it calls the Enterprise Server. Unlike some servers, it includes Job Queues and Subsystems to help manage limited resources. Its scheduling, logging, and notification features are useful. You can schedule jobs to run at off-peak times and even have it notify you by email or pager (if running the server on Windows NT) when the job completes. This provides you with added functionality that you wouldn't have if you just coded an application using a tool without a server, but there are many major application servers on the market. If you need a robust application server, that's a whole other product category beyond the scope of this review.

One of my chief complaints about JDesignerPro is that it installs using Microsoft's JVM, and you can't change that. A BulletProof representative told me that using JVM makes the product more stable, but it's a strategy that leaves JDP rather inflexible. Personally, I prefer a tool that I can point to a version of Sun's JDK as new versions become available. Bill Gates & Co. may own nearly everything under the sun, but they don't own Sun (or Java). Also, the Wizards generate deprecated code that uses the JDK 1.02 event model. BulletProof sees that as a good thing, because the 3.0 browsers do not use the JDK 1.1 event model. (On this one, I'll let you be the judge.) JDP does allow you to use Swing components, which is good, but according to a company representative, there's no timetable as to when JDP will work with JDK 1.2.

Another complaint: JDP cannot be customized. There are no environment or project options. There's no "Undo" option. There are no function keys or menu shortcuts. The product is mouse- and icon-driven. There is a Close command under the File menu, but it closes JDP, not the project on which you're working. I couldn't get JDP's main applet to run in Sun's appletviewer. There may be a way to do this, but it wasn't obvious to me.

Perhaps I could have figured it out, along with some of the other problems, if better documentation was provided. No printed documentation is available, and the online Help is not complete enough to eliminate the need for good, printed manuals. If you can't find an answer in Help and there are no manuals, where are you going to turn? BulletProof doesn't have an online knowledge database or newsgroup where you can resolve issues such as the ones I'm describing here, or review the issues that others are having. BulletProof claims that routing all problems through their technical support is beneficial because it makes them more aware of users' concerns. But they could still document those issues so that I could find answers without having to contact technical support each time. When I find that a company doesn't have a searchable "problems" area and a newsgroup on its product site, that's a red flag; without them, it's just too easy to hide problems.

Whenever I did call technical support during normal business hours, I got BulletProof's answering service. But on the plus side they usually responded to my emails within hours. So, most of my contact with the company was through email. My experience with other vendors' email support is usually measured in days. And I found BulletProof's technical support staff to be both helpful and knowledgeable. Peter Muller was especially pleasant to deal with. That's something I can't say about either Sun's NetDynamics or Symantec's Visual Café support.

Another major problem with JDP is that the product works better if you don't do any actual coding. If you add any code to methods that contain database fields, it may be overlayed. If you create a new method, JDP won't overlay the whole method, but you have to make sure that it is called by a line of code that you created with the interaction Wizard. There's no way to tell JDP to retain a line of code that you add to one of its methods. (When you do a build, it does warn you that it's about to overlay the methods where you added code, but that doesn't solve the problem.) Also, you can't even add your own import statements. Instead, you're forced to use the fully qualified names in all of your code. Normally, you might code this:

import java.text.*;
.
.
.
DateFormat df = DateFormat.getDateInstance();

Because you can't add the import statement, you're forced to code like this throughout:

java.text.DateFormat df = java.text.DateFormat.getDateInstance();

But by far the biggest complaint I have about JDP is that it builds everything from its own proprietary project format without using any Java code. It will generate Java code at the end when you do what's called a "final build," but it's after the fact. The tool doesn't work from the Java code at all; only from the project file. What made this situation worse is that my project files kept being corrupted. There were times when I couldn't seem to go any further because the project file was corrupt, so I started over with a whole new project. But later that project file also became corrupt. I could never find a pattern to explain what event or events caused the corruption. I learned to make frequent backups and archives of my project file, but that's just not acceptable. I sent a corrupt project file to BulletProof's technical support, but they were unable to fix it. At that point, Java source code (if you've done a final build) is useless for any more JDP project work.

I realize that every Java IDE has its problems and limitations, but I can't recommend JDesignerPro. BulletProof says, "Most people who use JDesignerPro have never programmed before in any language." If this is their target audience, then BulletProof has done well. But, as your experience grows, and your systems become more complex, you may find yourself frustrated with its limitations. "Two out of three ain't bad" may work for Meatloaf, but I think I'll stick with Elvis.