In-Depth
Java and J2EE: Attracting Developers May Depend on the IDE
Tool providers recognize the lack of interoperability is a serious problem, but solutions vary greatly.
If proponents of Java and the Java 2 Platform Enterprise Edition (J2EE) application framework hope to win over the hearts and minds of enterprise developers, perhaps they’d do well to take a page from Microsoft Corp.’s playbook: Start with a powerful and extensible development tool.
“It’s no accident that Microsoft ships the … most popular IDE [integrated development environment],” says industry veteran Rob Enderle, a principal with consultancy Enderle Group. If you’re writing code to exploit Microsoft’s .NET application framework, Enderle notes, there’s really only one tool that you need: The software giant’s Visual Studio.NET IDE. “[Microsoft is] as successful as they are because they give developers tools that are powerful and easy to use,” he concludes, noting that Visual Studio.NET is an extensible IDE that accepts third-party plug-ins designed by ISVs and other contributors.
Michael Hudson, a MacLean, Va.-based J2EE software architect, agrees. “I've only dived into the .NET world a couple of times, so I'm by no means an expert of .NET. But Microsoft does try to make a lot of this easier, and quicker to develop.”
The J2EE tools space is a comparative Babel, populated by about a dozen large vendors, each championing development tools that won’t interoperate nicely with one another. Oracle Corp., for example, markets Oracle 9i JDeveloper; Borland Software Corp., JBuilder; IBM Corp., WebSphere Studio and its open source variant, the Eclipse IDE framework; and Sun, NetBeans and Sun Studio. A host of other players—including BEA Systems Inc., Compuware Corp., and SAP AG—market competing development tools.
This vastly complicates the job of an ISV that develops and markets its own J2EE-based application and which ideally would provide plug-in support—such that enterprise developers could customize or otherwise write code in support of it—via an IDE. In the current state of affairs, an ISV needs to custom-code plug-ins for each of the IDEs that it wants to support. In the Visual Studio.NET world, on the other hand, ISVs need only write to Microsoft’s Visual Studio.NET APIs.
The good news is that tools vendors and J2EE proponents recognize that there’s a problem and are doing something about it. The rub, of course, is that they’re each doing very different things about it.
The Java Tools Community
On the one hand, a host of tools providers—spurred by the gang of two (Oracle and Sun)—are said to back an organization called Java Tools Community, which is an offshoot of a Java Specification Request (JSR)—JSR 198, “Standard Extension API for Integrated Development Environments,” to be precise—aimed at establishing a common API framework for Java IDEs. BEA, CompuWare, and SAP (among other heavyweights) are said to back Java Tools Community.
Because the Java Tools Community isn’t officially constituted as an organization, however, few of its reputed members have much to say about it at the moment. Besides, says Ted Farrell, chief architect for JDeveloper with Oracle, it’s the JSR 198 specification itself that’s really going to drive interoperability among IDEs. “The goal is to standardize those APIs, so that [developers] can write it once [in one IDE] and move it back and forth [among other IDEs]. We’re a big believer that if you standardize the APIs and the data, then the vendors can compete on the implementation. So [JSR 198] provides APIs so that ISVs can write extensions that work with multiple IDEs,” he comments.
Two big players conspicuously absent from the Java Tools Community fold are IBM and Borland. Both vendors support successful IDEs of their own design. IBM, for example, is a big supporter of Eclipse (on which its WebSphere Studio IDE is based) and touts it as an IDE framework to which ISVs can write plug-ins—in other words, more or less an open source equivalent of Microsoft’s Visual Studio.NET IDE. Big Blue kicked off Eclipse two years ago when it open-sourced $40 million of its own technology. Since then, says Skip McGaughey, chairperson for the Eclipse organization, the estimated value of the Eclipse code base has grown to between $60 and $70 million.
But will IBM join the Java Tools Community organization? Bernie Spang, director of WebSphere Studio for IBM, deflects the question. “All I can say is that [Java Community Tools is] not something that has been announced yet,” he says, adding: “IBM is very focused on our participation in Eclipse as a general open tools community. We certainly care about Java tools, but we don’t only care about Java tools. Our customers today are still mostly developing and maintaining COBOL and PL1 and C and other languages.”Eclipse enjoys the backing of hundreds of vendors, including heavyweights Oracle, SAP, and Sybase Inc., which are supporters of the Java Tools Community as well. But because Eclipse is an open-source initiative, its participation in the Java Tools Community will be determined by its governing board, and not by IBM itself. For his part, Eclipse chairperson McGaughey says that proponents of the Java Tools Community need to be more open about the scope, governance, and goals of the organization before the Eclipse board can make a decision.
“I am not totally clear what the JTO effort really is,” he says, noting that he has communicated with several of the organization’s supporters, some of which are also on the Eclipse board. “I have not seen, and they have not yet determined, exactly what this organization is: Who are the members? What are their missions? How do they remain open, not controlled or dominated by any one individual or group?”
Another potential spoiler for supporters of the Java Tools Community is Borland, which markets the popular JBuilder IDE, and which supports its own set of OpenTools APIs. Along with IBM—which last year acquired the former Rational Software Corp.—Borland is one of the few purveyors of development tools that support both the J2EE and .NET application frameworks.
No one knows if the absence of IBM and Borland will make or break the Java Community Tools organization, but most industry watchers note that the involvement of one or both players certainly wouldn’t hurt the nascent initiative. IBM won’t necessarily be on board by default if the Eclipse board opts to join Java Community Tools, either: Its WebSphere Studio IDE is based on the Eclipse framework, but features WebSphere-specific enhancements as well. So Big Blue’s absence could be a setback for the organization.
Sun's Latest Move
Still another setback occurred last week, when Sun declined to join the Eclipse project. Sun was technically the first of the large players to make available as open source software a Java IDE framework—NetBeans—on which its current SunStudio IDE is based. Although officials from Sun could not be reached for comment, McGaughey acknowledges that the Java creator’s absence from the Eclipse initiative is regrettable.
“For the last nine months, we have been working very closely with Sun, and sun has been working very closely with Eclipse, trying to figure out a way that we could make it worth Sun’s while to join Eclipse,” he confirms. “This involved everything from technology changes and discussions, to the point that we [Eclipse] were even willing to change the name of Eclipse, but sun for reasons that they need to articulate, chose not to join.”
Java programmers say there’s certainly a need for some kind of interoperability among IDEs, be it Eclipse, NetBeans, or JSR 198. Wenji Tong, a freelance J2EE developer who works primarily with BEA’s WebLogic application server, says that a lack of standardization among development tools is the root of many problems in enterprise J2EE development efforts. “Based on J2EE, people [have] so many choices on software solutions—[with] budgets from thousands of dollars to millions of dollars—that [this] may produce different results [from tool to tool],” he comments.
About the Author
Stephen Swoyer is a Nashville, TN-based freelance journalist who writes about technology.