Javaworld:

The tactic of "embrace and extend" is often associated with Microsoft. However, it seems that the Java 2, Enterprise Edition^TM (J2EE^TM) community has lately started to experience a similar phenomenon: As J2EE vendors' customers request features, those vendors are, naturally, obligated to provide those added capabilities in their J2EE app servers, leading to vendor-specific extensions. As developers take advantage of WebLogic-, WebSphere-, or SunONE-specific extensions, their code becomes less and less portable across J2EE implementations. Could that trend not lead to the same vendor lock-in the J2EE specs were supposed to protect against? Does the JCP, or some other Java process, address that issue?

Rob Gingell:

Earlier we talked about the tension involved in managing the froth on top of standards. In the J2EE marketplace the froth has thus far been pretty minimal. There are hundreds of thousands of downloads of the J2EE reference implementation [RI] from http://java.sun.com. By comparison, there are only a tiny number of J2EE products that make up the multi-billion dollar J2EE industry. Why all those downloads?

Developers of J2EE applications often use the RI as the development platform specifically to avoid getting inadvertently locked in to a specific J2EE implementation. At last Spring's JavaOne, we announced the application verification kit: A tool developers can use to inspect their applications to ensure that they're dependent only on what they're choosing to be dependent upon.

As a standard, J2EE has tended towards "minimal froth." That's good for customers in one respect, but it could be argued that it might be better if a few more competing enhancements existed beyond the specification. There's not an absolute right answer to this. It's a tension that needs to be maintained.

Early on, as the platform was being created, keeping the froth minimal was probably very helpful in bootstrapping the marketplace. With the marketplace seemingly well-developed at this point, do we do more advancement by bringing things through the JCP only, or do we do things in products followed by doing them in the JCP? Or do we do some things in the JCP that represent commonly agreed-upon attributes of new capabilities, leaving the not-agreed-on parts to be sorted out in products? How does one best find what "practice" to codify without doing some of it?

I don't think it should be a goal minimize the "froth." Part of managing the tension involves having a marketplace of developers who understand the trade-offs they're making, and a marketplace of customers that demand that the froth be kept in check. Using tools, such as the applications conformance kit, to ensure that, when developers and their customers choose to use a value-added, pre-standard feature, they know that they're using just what they need, and no more, and that their continued loyalty to that extension is dependent on it becoming common practice.

Ultimately, all standards exist to provide the economic service of telling us what not to waste time on anymore, to cover things in which variation is not value-enhancing and, in fact, is value-detracting. For technologies in rapid change, keeping things very close together helps accelerate the entire market and encourages adoption. For mature technologies, the boundary conditions become more the tolerance of the market.

Members of the JCP Executive Committee have held intermittent discussions about that issue. Happily, from my perspective, it's a very thoughtful conversation that has put hard issues out for people to talk about. There's never going to be "the answer" in terms of a set of absolute thresholds for defining what should be done in or out of the JCP. There's just this tension to be managed. That the JCP has been, and continues to be, a community dedicated to the proposition of compatibility having enabled the over 3 million Java developers speaks well of the desire to manage the tension to avoid destructive variation.

This interview was part of Javaworld's ongoing coverage of the Java Community Process. Visit http://www.javaworld.com for more articles on the JCP.

Frank Sommers is founder and CEO of Autospaces, a company dedicated to bringing Web services and Jini to the automotive sales and finance industries. He is also Editor-in-Chief of the Newsletter of the IEEE Task Force on Cluster Computing, and Javaworld's Web services and Jiniology columnist.