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.