As Published In July/August 2003

Getting Hooked in Java

By Joe McKee

Oracle-led JSR-198 seeks to bridge the gap between Java IDEs.

Whether it's Oracle9i JDeveloper, JBuilder, NetBeans, Eclipse, or any of the number of integrated development environments (IDEs) out there, Java developers the world over know there isn't one all-encompassing IDE that meets all Java needs. IDEs often get riddled with extensions and plug-ins that developers either build or download and install to provide greater functionality to their development platforms.

"It's the reality we work in," says Ted Farrell, director of strategy at Oracle's application-tools division. "We openly recognize that developers extend their IDEs and use a combination of tools to build and deploy their applications."

The problem is that different Java IDEs use different extension application programming interfaces (APIs). A plug-in or extension built for JDeveloper is unavailable to developers using Eclipse unless the extension builder codes a separate version.

Under the Java Community Process (JCP), Oracle and other toolmakers have proposed JSR-198, a single API for Java tools, in order to bridge the Java IDE divide.

Jose Cronembold, a senior development manager for Oracle and specification lead for JSR-198, explains, "People who build Java development tools and extensions have to choose which platform their extensions will run on. The decision to support only one Java IDE toolkit framework shuts out an entire Java IDE audience that might want that extension functionality."

"As a developer, depending on the complexity, you may have to repackage an application in order to have it operable within another IDE," Oracle's Farrell points out. "For an open-standard language like Java, application portability is a key principle, and it should be just as important when it comes to development tools."

Extensions Do Matter

Average Java developers may think the proposed API under JSR-198 doesn't affect them, since they don't code custom IDE extensions. "The truth is that JSR-198 does affect average developers," says Farrell. "Most developers may not write IDE extensions, but nearly everyone uses them at some point."

Farrell adds that most extension and plug-in builders are often a single person or a small team working with limited resources. "They have to choose what IDE they're going to code to," he says. "If they're lucky, a really good extension might be built for two IDEs. So, suppose you like a particular extension that some small company came up with. But suppose that company had to choose what IDEs the extension would work with and went with JDeveloper and JBuilder. But you use IntelliJ. JSR-198 is meant to give that company a standard way to hook into Java IDEs so that the average developer can access that extension regardless of the IDE choice."

Oracle's Cronembold adds that developers often get boxed in because IDEs lack this standard API for extensions and plug-ins. "Developers should be able to mix and match the extensions they want with the IDE they prefer. In the end, JSR-198 is about making more choices available to developers."

Extending IDEs via Standard Hooks

Good developers are known for creative solutions, and, once they find them, they often make their solutions available as plug-ins or extensions that can work within an IDE. "For example, a developer might have created a UML modeling feature that can work with a modeling editor," says Cronembold. "There are several places to hook this custom feature into a particular IDE. Maybe the development team wants to hook into their IDE via its standard menu bar, or maybe a custom tool bar, or part of the editor itself. Currently, they'd have to code a custom 'hook' for individual IDEs. Maybe they only have time to code it for Eclipse. That means that all other IDEs can't use it."

"A lot of people in the Java community want this to change," explains Oracle's Farrell. "Developers want a single point of entry for Java IDEs so they can code to that standard and know that their extensions or plug-ins will work within any IDE."

"People get attached to their favorite tools," adds Cronembold. "We're not advocating massive changes to graphical user interfaces. Much of JSR-198 is about non-GUI issues."

Essentially, the expert group's proposed JSR-198 API focuses on standardizing the process and mechanisms of adding extensions and plug-ins, allowing the IDE's GUI model to remain intact. Non-GUI items include representing Java classes in the structure model in a standard manner. Under JSR-198, extension developers will have a single way to interact with Java classes and the structure model within the IDE.

This strategy sounds simple for something that's actually complex. For example, a developer may build a custom filter or need to have a class reformatted to make it more presentable. These are standard IDE functions that can sometimes get tripped up if a lot of extensions and plug-ins are installed. With the JSR-198 API implemented, any installed plug-in or extension will operate as if it were native to the IDE and will not frustrate a developer during coding.

Other behind-the-scenes work includes standardizing extensions that establish customized preferences. "These can be very simple preferences within an editor, like setting up indentation or color coding for keywords," says Cronembold. "Developers may want to use these custom preferences on a component, but not for entire projects, so they don't want to establish these new preferences for the IDE as a whole. There are extensions out there that make this process easier. JSR-198 proposes a standard way for these kinds of extensions to work within any Java IDE editor. Developers would simply activate the extensions within the native editors that they're already familiar with.

Next Steps READ more about JSR-198 /oramag/jsr198.html www.jcp.org/en/jsr/detail?id=198 At the time of this writing, the proposed API under JSR-198 was still in the editing process. Items will likely be added, deleted, and changed as the interface moves through the Java Community Process.

"We are planning on doing some simple things within the GUI," adds Cronembold. "The initial proposal included a request for undo/redo support, for example, so extensions can plug into an IDE's undo/redo mechanism without being custom-coded. Also, JSR-198 seeks to specify a standard way that developers can address their files through a URL so that they don't have to play with strings. This way, it doesn't matter where the file resides as long as the URL is properly constructed."

Differences of Opinion

On the face of things, getting JSR-198 through the approval process seems like a clear-cut case. One issue, however, is that the IBM-supported Eclipse IDE is SWT-based and technically isn't part of the J2SE standard, whereas AWT/Swing IDEs are part of the proposed protocol. Despite some tensions between the two sides, members from both the SWT proponents and the AWT/Swing camp are working together to find common ground.

"Oracle's JDeveloper is AWT/Swing, but Oracle also joined the Eclipse board of stewards," says Oracle's Farrell. "IBM, the primary backer of Eclipse, is also on the expert group for JSR-198, so this is a cooperative effort. Companies that build IDEs, such as BEA, Macromedia, Sun, SAP, and JetBrains, are also on the expert group."

"Everyone has preferences when it comes to IDEs, and that's the whole point behind JSR-198," Cronembold acknowledges. "We want to give extension writers a single API in order to give developers the freedom to extend their personally preferred IDE without worry."

Joe McKee (words4hire@hotmail.com) is a freelance reporter covering emerging internet technologies. He has 10 years' experience in software development and WAN design.

AWT, Swing, and SWT Java Foundation Classes (JFC) are the Java standard implementation for cross-platform graphical user interface (GUI) and graphics development. Two of the core pieces of the JFC are the Abstract Widget Toolkit (AWT) and the Swing GUI components. The Eclipse project—an IBM-founded consortium—went in another direction with its Java GUI and graphics library and created the Standard Widget Toolkit (SWT). AWT enables programs to integrate with the native components of the desktop window system. The advantage to using native components is that programmers can access more native functionality, and native components look consistent with the rest of the applications on a particular operating system. Since AWT supports multiple and diverse operating systems, however, the AWT APIs are limited to the common functionality across the different systems. Swing is a set of APIs that extend AWT. Swing components are "lightweight" components in that they do not use native components but instead draw themselves on a native window using a look and feel that is determined by the programmer. One advantage to this approach is that Swing components are not bound by any operating system. They can consistently draw themselves regardless of the underlying native components, because they don't use them. Almost all Java-based applications today that have a user interface are written using the Swing GUI components. SWT is a set of native components designed to provide efficient, portable access to the user-interface facilities of the operating systems on which it is implemented. Although SWT is similar to AWT because both use native components, SWT maps to native components in a different way, so that SWT components are also able to provide a rich set of functionality, like Swing components. Unlike AWT and Swing, however, SWT is not part of the Java Community Process.