|
|
|
|
Sponsored Link •
|
|
Advertisement
|
Frank Sommers: The tactic of "embrace and extend" is often associated with Microsoft. However, it seems that lately the J2EE community has started to experience a similar phenomenon: As customers request features, J2EE 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 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 minimal. The multi-billion dollar J2EE industry is made up of a small number of commercial J2EE products. The J2EE reference implementation, which can be downloaded at no cost from http://java.sun.com, has hundreds of thousands of downloads. Why all those downloads?
J2EE application developers often use the reference implementation as the development platform, specifically to avoid getting inadvertently locked in to a specific J2EE implementation. At last year's JavaOne, we announced the Application Verification Kit: A tool developers can use to ensure their applications depend only on what they choose to depend upon.
As a standard, J2EE has tended towards minimal froth. That's good for customers in one respect, but you could argue it might be better if a few more competing enhancements existed beyond the specification. There is no 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 helpful in bootstrapping the marketplace. With the marketplace seemingly well-developed at this point, do we initiate more advancement by only bringing things through the JCP, or do we do things in products and then bring them to the JCP? Or, do we develop some things in the JCP that represent commonly agreed-upon attributes of new capabilities, and sort out the not-agreed-upon parts in products? How does one best find what practice to codify without doing some of it?
I don't think we should aim to minimize the froth. Part of managing the tension involves having a marketplace of developers who understand their trade-offs, and a marketplace of customers who demand the froth be kept in check. Tools, such as the Applications Verification Kit, ensure that when developers and their customers choose a value-added, pre-standard feature they know they're using just what they need—and no more—and that their continued loyalty to that extension depends on it becoming common practice.
Ultimately, all standards exist to advise us what not to waste time on—to cover things in which variation is not value-enhancing and, in fact, is value-detracting. For technologies in rapid change, keeping things close together helps accelerate the entire market and encourages adoption. For mature technologies, the boundary conditions become more what the market can tolerate.
Members of the JCP executive committee have held intermittent discussions about that issue. From my
perspective, it's a thoughtful conversation that has presented hard issues for people to talk about. There will
never be an 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 more than three million Java developers,
speaks well of the desire to manage the tension to avoid destructive variation.
Rob Gingell asked several interesting questions in this paragraph:
Early on, as the platform was being created, keeping the froth minimal was probably helpful in bootstrapping the marketplace. With the marketplace seemingly well-developed at this point, do we initiate more advancement by only bringing things through the JCP, or do we do things in products and then bring them to the JCP? Or, do we develop some things in the JCP that represent commonly agreed-upon attributes of new capabilities, and sort out the not-agreed-upon parts in products? How does one best find what practice to codify without doing some of it?Have an opinion? Discuss this article in the News & Ideas Forum topic, Froth and Compatibility
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 Artima.com's Web Services
columnist.
Resources
The Java Community Process home page:
http://www.jcp.org/en/home/index
Information on the Java Application Verification Kit for the Enterprise:
http://java.sun.com/j2ee/verified/
Overview of the Java Community Process:
http://www.jcp.org/en/introduction/overview
Timeline through which a JSR passes as it makes its way through the Java Community Process:
http://www.jcp.org/en/introduction/timeline
JCP FAQ:
http://www.jcp.org/en/introduction/faq
A brief summary of the Java Community Process procedures:
http://www.jcp.org/en/procedures/overview
Overview of Java Service Requests (JSRs):
http://www.jcp.org/en/jsr/overview
|
Sponsored Links
|