Proprietary J2EETM extensions
The tactic of "embrace and extend" is often associated with Microsoft. However, it
seems that the Java 2, Enterprise EditionTM (J2EETM) 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
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
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