Speaking to Sun's J2EE marketing team recently, we learned that J2EE 1.4 has been delayed so that "vital" new Web services features could be added. Originally targeted for the second half of 2002, J2EE 1.4 FCS is now not expected until this summer.
J2EE is perhaps the most significant of the three Java platform "editions" - Micro, Standard, and Enterprise. It's usually J2EE that is stacked up against .NET in the marketplace. Delays to J2EE releases significantly impact on the extent to which Enterprise Java can maintain and improve its market penetration.
I question whether Sun's current monolithic approach to the Enterprise Edition is either appropriate or effective. On the one hand, J2EE 1.4 is just another set of specifications going through the Java Community Process (JCP); like all standards processes, that's bound to mean compromises and delays as competitors sit around the table to hammer out the details. But J2EE is a big beast, as we've all learned from bitter experience:
Coping with problems caused by unstable and changing dependencies is always best avoided if possible.
Although it may suit the giants of the industry - BEA, IBM, Oracle, and Sun - to have a megaspecification, this discriminates against specialist vendors who cannot benefit from the compliance test suite for an individual component, but are legally bound to license the entire J2EE stack - all or nothing. That could be seen as an excessively restrictive barrier to entry; in these hard times, small vendors simply can't afford to meet the same licensing fees as the big players. Some simply evade formal licensing and compliance, while others are driven out of J2EE development entirely. Sun is now offering open-source projects free-of-charge access to the compliance tests, which will further squeeze out the smaller vendors who historically have driven innovation in this industry.
How Can We Redress the Balance?
Developers increasingly base products and solutions around just those subsections of the J2EE platform that they need, and they don't like being forced to pay for components, such as EJB, that they don't use.
Forward-thinking infrastructure developers are building plug-and-play Java platforms that make it possible to assemble your own style of server. Servlet or EJB container doesn't quite suit your needs? Then assemble your own purpose-built container!
Look at how the JBoss microkernel is blossoming; take a glance at Jakarta's Avalon and Phoenix projects. This is the way of the future - modular, easily customizable, and extensible server frameworks, on top of which architects can combine subsets of J2EE with components like Java Data Objects (JSR-12), the Java Rule Engine API (JSR-94), or JCache (JSR-107) that are - for the moment at least - outside the J2EE boundary.
Mix and Match
With the Mobile Edition (J2ME), sheer physical constraints forced the acceptance of different horses for different courses; J2ME's configurations and profiles ensure that for every requirement the right platform can be assembled, without undue fragmentation of the standard.
I propose that for J2EE 1.5, Sun and the JCP should isolate the minimum kernel required to support enterprise infrastructure. Perhaps JCP can learn from Extreme Programming practices and organize a series of easier-to-control "sprints" rather than another 18-24 month marathon. The "optional extras" like EJB, JSP/servlets, JDBC, and JMS can each have an independent-release cycle; each one must be transparently pluggable into any vendor's core J2EE kernel; no vendor specifics allowed. At the same time, Sun should change its J2EE licensing policy to a "per-component" basis, priced accordingly.
Architects can then easily assemble the configurations they need - such as the frequently touted J2WE or Web Edition - reducing the costs of development but retaining all the advantages of interchangeable standards-based components. Each component can be upgraded much more quickly, and "Write Once, Run Anywhere" comes another step closer.
Author Bio
Nigel Thomas is director of product management at SpiritSoft.
nigel.thomas@spiritsoft.com
