PowerBuilder Authors: Chris Pollach, Yeshim Deniz, Jayaram Krishnaswamy, Kevin Benedict, Avi Rosenthal

Related Topics: PowerBuilder

PowerBuilder: Article

What's New in PowerJ 4.0?

What's New in PowerJ 4.0?

PowerJ, Sybase's Java/J2EE development tool, is reaching a new phase in its evolution. With the soon-to-be-released PowerJ 4.0, the product has been given both an external and internal overhaul, and is a much more usable tool as a result. PowerBuilder developers will find the UI a lot more familiar than earlier versions of PowerJ, and J2EE component developers will find many new compelling features that will enhance their productivity.

General Usability Features
MDI Development Environment

Unlike many common development environments, prior versions of PowerJ had an SDI development environment. While this left more room for the editors, it was generally confusing in practice, with multiple overlapping windows that were difficult to manage. So, PowerJ 4.0 is now a fully MDI development environment, similar to PowerBuilder or any number of other such IDEs.

Tidbit: Internally, PowerJ has been designed to operate in either MDI or SDI mode, choosing which to use at initialization. Since all testing efforts have been devoted to the MDI mode, this feature is of no practical benefit, but perhaps this may serve as yet another example of how good design can increase the scope and power of your code.

ToDo Lists
PowerBuilder developers will no doubt be familiar with ToDo lists, which have now been brought to PowerJ. They look and feel the same as in PowerBuilder, so the PB developer can use them right away. ToDo list items can be set up for any editor, including the embedded editor in the right pane of the Views window and any form.

Enhanced Support for Using .java Files Directly
PowerJ has a strong tradition of allowing developers to quickly write Java code without necessarily having to understand the underpinning code. In addition, PowerJ has always, and will always, do its best to help the developer be as productive as possible. However, previous versions of PowerJ were somewhat limiting in that they forced the user to accept PowerJ's help, whether he or she wanted it or not. With PowerJ 4.0, the focus has been shifted to providing help when asked, but staying out of the way when not asked. No feature better illustrates this than this one. You can now choose, with pinpoint accuracy, when you would like PowerJ to manage your code and when you'd like to manipulate the source directly.

If you choose to manipulate the source directly, PowerJ will continue to provide as much assistance as it possibly can by introspecting the contents of your code at appropriate intervals, and allowing you to change properties of existing components, insert new components, or delete old ones, all through the use of property sheets, design-time form representations, or object inspectors. PowerJ will perform this introspection when the editor for that code loses activation or is closed; or when a property is changed via the object inspector, a property sheet, or by manipulating the objects on the design-time form. However, PowerJ won't modify your code unless you change a property in one of the aforementioned three ways.

PowerJ in no way restricts the contents of your source; it injects no comments and enforces no coding style. When injecting new code, PowerJ attempts to respect the current coding style with regard to indentation and location.

Aside: Since PowerJ uses parsing instead of compilation to determine the intent of the code, it's possible to "trick" PowerJ into missing the declaration and/or instantiation of objects, or to insert new objects into an inappropriate location, much like it's possible to "trick" other Java development tools. But PowerJ attempts to be as robust as possible, so a simple try-catch block, for example, won't cause it to miss code.

The Reference Card is PowerJ's traditional method of supplying information about a given component's methods and said methods' return and parameter types. While the Reference Card continues on in PowerJ 4.0 with enhancements, a new AutoScripting feature has been added to the PowerJ editor to provide a slimmer, more readily accessible way to access the same information. It's accessible through shortcut keys or menu items when in the editor, so the user can quickly scroll through the list of methods that match the component and partial method name currently supplied, and have the method name and parameters filled in automatically. AutoScripting will never occur if the user doesn't want it to; it's there if you need it, but it won't get in your way.

Saveload Format Changed to XML
PowerJ's internal, proprietary saveload format has been changed to XML. This is of no obvious immediate value to the user, other than that by copying a PowerJ file to an .xml extension, you can use any XML browsing tool, such as Internet Explorer, to quickly navigate the contents for informational purposes.

J2EE Features
JDK 1.3 Support

PowerJ 4.0 will explicitly support three JDKs: 1.1, 1.2, and 1.3. With PowerJ 4.0, the flexibility of JDK usage has been dramatically enhanced. You can now choose any combination of design-time, build-time, and runtime JDKs. PowerJ has also been restructured internally to make it dramatically easier to plug and play JDKs dynamically.

Trick: Advanced users may wish to try adding additional, unsupported JDKs by duplicating the structure of existing JDKs in the HKEY_LOCAL_MACHINE\Software\Sybase\ Optima\4.0\Java\JDKs registry key.

J2EE 1.3 Support
One of PowerJ's primary goals is making J2EE development as easy as possible, and that of course means supporting J2EE 1.3. So PowerJ has added new EJB 2.0, Servlet 2.3, JSP 1.2, and Taglib 1.2 targets.

Tag libraries were not explicitly supported in previous versions of PowerJ, but that has been addressed in 4.0 with both Taglib 1.1 and 1.2 targets. The wizard is usable for both experts and people who don't know the difference between javax.servlet.jsp.tagext.BodyTagSupport and javax.servlet.jsp.tagext.TagSupport, or what to return from doStartTag(), doEndTag(), and doAfterBody() under what circumstances.

EJB container-managed persistence (CMP) support has been added in full force to PowerJ 4.0, and EJB 1.1 and 2.0 CMP. An intuitive wizard guides the user through the options, aiding the user in specifying compound or single-field primary key classes, even to the point of automatically generating a compound primary key class.

PowerJ 4.0 also can optionally have the remote interface be automatically generated by introspecting the contents of the implementation class, thus allowing the user to concentrate on developing the functionality of the EJB, not on how it's accessed.

Trick: Advanced users can also manipulate the default behavior of most J2EE wizards by changing the values of registry string values such as HKEY_LOCAL_MACHINE\Software\Sybase\Optima\4.0\DefaultEJBJavaPackageName and HKEY_LOCAL_MACHINE\Software\Sybase\Optima\4.0\DefaultServletExtends.

Deployment to Multiple Application Servers
Earlier versions of PowerJ could only deploy to the corresponding version of EAServer. Following the philosophy of JSR 88, PowerJ's deployment mechanism has been abstracted as much as possible, and is completely insulated from changes in implementation. So now PowerJ 4.0 can support not only EAServer 4.0, but also EAServer 3.6.1 and ASE 12.5.

Tidbit: Interested users may wish to reverse-engineer the classes in the $PowerJ40\java\lib\com\sybase\jaguar\deploy and $PowerJ40\ java\lib\powersoft\powerj\browser folders. While these classes and interfaces are for internal use only and are subject to change without notice, they should prove of interest to users wishing to replicate the same EAServer version independence in their own code.

Application Server View
While Jaguar Manager is a powerful and flexible management tool, PowerJ users have often expressed the desire for a lightweight version of that functionality embedded right in the tool, to prevent having to constantly switch between the two. With PowerJ 4.0, a new Application Server view has been added alongside the Workspaces, Objects, and Internationalization views.

The Application Server view provides, on demand only, the Servers, Connection Caches, Listeners, Applications, Web Applications, Servlets, and Packages treeviews for a given application server profile. Figure 1 provides a prerelease snapshot of this view. Each component lists all its methods, including information about return and parameter types. Components can also be imported onto the PowerJ component palette directly from this view. In addition, each server can be restarted or refreshed from this view. And again, because of the independence of the application server connectivity code, you can simultaneously browse different versions of application servers.

Enhanced Support for Integrating Existing JSPs
While PowerJ provides a JSP target to quickly generate a simple JSP file, in addition to supplying automatic deployment descriptor generation and an easy-to-use UI for editing that information, creating a separate target for each JSP file can be burdensome. For PowerJ 4.0, deployment descriptor information is now associated with the JSP file, rather than with the JSP target. So you can add multiple JSP files to a single JSP target and/or WAR target and have each JSP file maintain its own separate deployment descriptor information.

Enhanced Support for Integrating Existing EJBs
While the EJB target wizard is an extremely convenient, understandable way to create new EJBs, the possibility does exist that users will have written EJBs by hand, or even, gasp, in a different development tool. So the EJB wizard in PowerJ 4.0 allows users to specify whether they wish to create the new target with existing source files or by creating new source files as before. Should the user choose existing source files, the wizard will introspect that source and automatically pick up such information as to whether the source represents a session or entity bean, to prevent the user from having to enter redundant information.

Enhanced Debugging
PowerJ 4.0 uses primarily JPDA debugging, and can thus debug into any number of third-party VMs that support that API. In addition, PowerJ's debugging has been radically overhauled to make it easier to simultaneously debug multiple targets running inside of multiple VMs. And finally, PowerJ will support JSP debugging, at least within EAServer. The full extent of PowerJ's debugging support wasn't thoroughly threshed out at the time of the writing of this article, but the debugging support will easily be the most robust in recent memory.

Allowed Disabling of Automatic Deployment Descriptor Generation
One of the ways in which PowerJ makes J2EE development easier is to provide a readily understandable interface for managing deployment descriptor information (META-INF\ejb-jar.xml for EJB JAR files, WEB-INF\web.xml for WAR files, META-INF\application.xml for EAR files), and automatically generating said deployment descriptors. However, some users may wish to, at least occasionally, use their own deployment descriptors, and thus PowerJ 4.0 allows the user to prevent PowerJ from automatically generating deployment descriptors.

PowerJ 4.0 contains many more features and enhancements, but I've listed the most significant. PowerJ 4.0 now has a lot more style and substance, and I heartily encourage you to take it for a spin when it comes out. I think you'll be pleasantly surprised.

More Stories By David Brandow

David Brandow, a software engineer at Sybase, Inc., has been been a key developer on Power++, PowerJ, EAServer, WorkSpace and SUP. David obtained a BMath from the University of Waterloo.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.