answer to Java-centric IDEs such as Microsoft's J++, Symantec's Visual Cafe Pro, and Borland's soon-to-be-released Visual JBuilder. But a future PowerJ may add C++ as well.
Optima++ Outside, Java Inside
On the surface, PowerJ looks and works much like Optima++. Its application construction uses the ubiquitous "form with tool palette" paradigm. The prerelease version of PowerJ I tested had about two dozen components on the tool palette. I suspect there will be more by the time Powersoft releases PowerJ.
PowerJ includes the reference-card programmer-assistance mechanism well known to Optima++ developers. When you drag a component from the form and drop it into the source code window, the reference card opens, positioned to the list of event-handling me
thods that the selected object can accept. If you choose to call a method, the parameter wizard guides you through entering that method's required parameters. The parameter wizard is a kind of "active lint." It verifies not only that you have filled in all the requisite parameters, but that you've used parameters of the proper type.
PowerJ manages events for visual components in a manner that's almost an inverse of the technique that the new JDK 1.1 supports. For example, in PowerJ, when you place a button on the form, you identify which events that button will handle (e.g., click) through the button's property inspector window.
Once you've named a handler for the event, PowerJ will pour an empty skeleton for that handler into your source code. Therefore, if I had named the click handler
btn1_click
, PowerJ would write an empty
btn1_click
method into the source. I would then populate that method with the code that I would want executed whenever I clicked on that button. Typically,
the code would modify data members of other objects in the form: Clear a text box, for instance.
However, JDK 1.1 uses a "delegation" event model, wherein events propagate from source objects to listener objects. To recast the above description in the delegation model, the button would become a source object and the text box would become a listener object. The text box would register itself with the button, informing the button that: "I want you to call this method of mine whenever you're clicked on." The code for clearing the text box, rather than appearing in the
btn1_click
method, would be written into the listbox's listener method.
This dissimilarity is ungainly but not disastrous. Even version 1.1 of the JDK's Abstract Windowing Toolkit (AWT) -- which is where all this event handling takes place -- will be backward-compatible with the event model supported by the previous JDK (and around which PowerJ has wrapped its event handler).
Happily, at press time, officials at Powersof
t told me that its event-handling code was undergoing some rewriting, specifically to bring it in line with JDK 1.1. In any case, one of PowerJ's benefits is that it insulates you from the event model. It's unlikely that -- even after the rewrite -- the mechanics of working in PowerJ that I've described here will change.
PowerJ and the Bean
PowerJ is open-minded in its treatment of components. PowerJ applications can employ either ActiveX components or Java bean components. The balance is not perfect, however. Though PowerJ programs can interact with ActiveX controls, the PowerJ environment does not let you build them. In contrast, you can build Java bean components with PowerJ.
Building a Java bean with PowerJ is straightforward, as is incorporating beans into your IDE. PowerJ's documentation guides you through the necessary methods and properties you must incorporate into your bean. Once your bean is built, programmers can add it to their palette of components, at which time t
hey can treat the bean the same as PowerJ's supplied components (i.e., the bean's object inspector provides access to the bean's properties, and its methods and parameters are available to the reference card).
However, PowerJ has only partial true bean support. Specifically, it does not support the Java bean customization class (as defined in JDK 1.1), which provides for design-time modification of a bean's properties. Nor does PowerJ support "pickling" a Java bean, which means adding persistent storage of a specifically configured bean for later use. (Pickling is dependent on the customization class. Without the latter, you cannot have the former.)
None of this means that you cannot modify PowerJ beans at design time, nor pass them from one PowerJ project to another. However, PowerJ beans may not be fully compatible with JDK 1.1 beans. (I say "may" because the 1.1 specification is still in beta testing as I write this.) I was told that the PowerJ engineers are considering support of customization
classes and pickling, so they may be in PowerJ now.
On the Launchpad
Powersoft expects to ship PowerJ in this second quarter, and it will be available on Windows 95 or NT 4.0. Additionally, the release version will provide client/server development tools not yet in the version I saw, including jdbcConnect -- which provides a "thin-client" Java Database Connectivity (JDBC) API -- and NetImage Dynamo -- a server-side product that can accept SQL queries passed in from a Web server, process them against any ODBC database, and return an HTML-formatted query result.
PowerJ is an admirable Java IDE. Anyone familiar with Optima++ will slide easily into the PowerJ seat. Furthermore, PowerJ and Optima++ share identical IDEs. The company says that it may integrate the two products into one environment. If this happens, you could use the same environment to build either C++ or Java code.
Product Information
Sybase, Inc. (division of Powersoft)
Waterloo, Ontario, Canada
Phone: 519-886-3700
Fax: 519-747-4971
Internet:
http://www.powersoft.com
Jet-Assisted
Java
