At JavaOne, Jonathan Schwartz, executive vice president of Sun's Software Group, outlined his mission to increase the number of Java developers from 3 million to 10 million. The hope is to attract these extra seven million from the legions of Visual Basic (VB) developers. Visual Basic's strength comes from a tool experience that is inseparable from the language and, in order to capture their mind share, Java needs the killer IDE.

Early Java programming books were often bundled with a copy of Visual Café, allowing readers to concentrate on learning the language syntax instead of esoteric JDK command syntax. While some programmers pride themselves on writing macros to customize their favorite text editors, integrated development environments (IDEs) offer the easy life of code assist, incremental compilation, and integrated debuggers.

Since Visual Café, a number of great IDEs have been created. JBuilder, IntelliJ, and Eclipse lead the 2003 JDJ Readers' Choice Awards with TogetherJ, Oracle9i Developer, and Sun ONE all equally worthy of pole positions. The irony is that having so many good development tools is a weakness, not a strength, when it comes to tackling Microsoft.

The current Java IDE landscape makes extensibility APIs either constrained to the lowest common denominator or proprietary to each vendor. JavaBeans and JavaServer Faces (JSF) are examples of the former because, while components can be good citizens for how a tool will use them, they cannot exercise sufficient control over the environment hosting them. To truly leverage a tool requires knowledge of its object model for representing artifacts, the life-cycle API for how data is persisted, and the control of event notification between viewers. If the IDE surfaces these internals to the component, a much richer edit time experience can be created. The case in point is Microsoft Design-Time Control (DTC), which allows customization of Web page components through in-place ActiveX controls that run within the source editor. Java's answer to DTC is JSF. Without being able to surface a satisfactory mechanism to plug into the IDE's viewers, the source-editing experience relies on using the JSF component as you would any other JavaServer Page (JSP) tag library or JavaBean. This is not going to lure the VB crowd who want in-place preferences dialogs for their component embedded directly in the source page.

The most successful challenge to Microsoft tools in the Java space so far is to adopt a proprietary approach as used by JBuilder, IntelliJ, or Eclipse. These surface the APIs that tool vendors and component builders need to leverage the edit time experience. However, their bespoke interfaces cause fragmentation in the tools space, and while JSR 198 is a well-intentioned attempt to resolve this problem, it's too little too late and is fated to become the lowest common denominator.

Any successful extension API needs to be more than skin deep, and what motivation do the tools vendors have to come together and agree on a common object model or life-cycle API? It is IBM's doomed AD cycle all over again. If a compromise API is reached, the IDE vendors will do half-hearted shoe horning of this into their existing tool, while still retaining their internal extension APIs for serious platform development. The issue is further complicated by the inability of Swing and SWT to interoperate, and if the GUI toolkit can't be agreed upon, there is surely little hope that the internals can converge.

The only solution I see is for one of the existing IDEs to become the de facto tool for Java. The benefit of having only one tool is that people can program to its extension API, have access to the internals of its object model and construction and, in an ideal scenario, the tool would be offered with JDK downloads to round off the whole Java "out of the box" experience. This way when the seven million newcomers we are hoping to attract first taste Java, they feel at home with a rich set of design-time tools fully integrated with the language.