Java Tools Consortium: Just What We Needed?

As the new year burst onto the scene, a group of software tools and middleware makers joined Sun Microsystems, the creator of the Java programming language, in establishing the Java Tools Community. There’s been much noise about whether it has any real purpose or teeth, and whether it poses a threat to the IBM-backed Eclipse consortium or the Sun-backed NetBeans project, both of which are trying to deliver open-source integrated development environments for Java.

Sun is positioning the Java Tools Community as an adjunct to the broader Java Community Process, which it uses to decide what goes into the Java programming language, its compilers, and its virtual machines. While Sun is arguably “open,” in as much as it vets good ideas for the enhancement of Java, the company has remained firmly in control of Java since its launch in the mid-1990s, and it shows no sign of trying to make Java a truly open standard that lets other vendors, like IBM and Microsoft, directly control Java through a standards body, much as the SQL database query and programming language is controlled by the industry and not just one vendor. (IBM invented SQL three decades ago, by the way, and let go of it after a bit of prying.)

The Java Tools Community, or JTC, is a mechanism by which Java Specification Requests, which have to do specifically with Java tools, can be better steered so that Java tools get better, APIs are not so cryptic, and Java features can be interoperable across different tools from third-party tool makers. The result, JTC members hope, is that Java programming can get easier, which, in turn, should drive up the adoption of Java technologies. Sun, database and middleware maker Oracle, middleware supplier BEA Systems, and ERP application giant SAP are the anchor members of the Java Tools Community. Tool makers Compuware, Iopsis Software, JetBrains, and Quest Software have joined the group, as has analytics software maker SAS Institute. Notably, the key members of the Eclipse group, including IBM, Borland, Intel, Red Hat, and SuSE, have not joined the JTC. Oracle and SAP are members of both camps, and Microsoft, which is doing its own thing with .NET, hasn’t joined either, and obviously will not.

It is probably not a coincidence that the JTC was launched a few weeks after Sun decided not to join the Eclipse project, even after the consortium made some concessions clearly aimed at appeasing Sun in late November. For whatever reasons, Sun didn’t join. (The rumor is that it really didn’t like the name Eclipse, and didn’t like that IBM is really in control of it.)

This may sound like kindergarten sandbox fighting, but a lot is at stake for the companies and professionals who have staked their careers on Java. Sun reckons that there are about 3 million Java programmers, and it wants to get that number up to 10 million within the next few years. The race is on to get as many Java adherents as possible before Microsoft cranks up the C#, Common Language Runtime, and .NET alternatives to Java, JVMs, and J2EE. Numbers will matter in this war of the languages.

What the JTC looks like is another layer of bureaucracy that gives tool makers some input into how Java evolves. But JTC members are not contributing code, and, in fact, they are not doing any coding for Java Specification Requests that get accepted for Java standards. This is really a lobbying organization; whereas organizations like Eclipse actually get down to the dirty work of coding to create the tools that let programmers implement Java APIs and embody tool-related Java specs. The JTC may speed up the creation of better Java tools, particularly if IBM, Borland, and other Eclipse members join and add their weight to the JTC. But, then again, it may slow down the whole process. Microsoft is only one company, and when it moves in a direction, the .NET market will have to follow.

What Java really needs is a single organization to coordinate the adoption of Java standards and the coding of Java APIs, and of the development environment and tools in order to implement those APIs. There are too many tool vendors delivering too many competing products, and Eclipse at least has the idea of creating a single tool framework that would let other tools snap into the framework. A consistent look and feel across many tools is a very useful thing.

The Java world would be a much better place if Sun and IBM would bury the hatchet and create a single, unified Java consortium that owned all Java intellectual property, let everybody contribute ideas to the Java standard, solicited open source implementations of those standards (like Linux and Apache do) by open source projects funded by the Java consortium members, and yet still allowed all consortium members to innovate and differentiate so they could make some money. This consortium could license Java and pay Sun for the work it has done, which the world will benefit from over the year, which is fair and just. Other Java contributors should get royalties where appropriate, too. Maybe no one gets any royalties from this point forward, just like no one makes direct money on the Linux kernel.

The important thing is that a truly open standards, open source approach to Java is the best weapon against a rich and powerful Microsoft and its .NET, which will become a de facto standard if this infighting in the Java world doesn’t stop. Neither Sun nor IBM makes any direct money off of Java, and they should admit that and move on. They stand to make lots of money selling servers, software, and services running Java applications if Java takes off, as it should have a long time ago. If Microsoft had been part of Java from the beginning, and the force of the consortium could have been brought to bear on it, .NET would have never happened, and quite a few lawsuits might not have, either.