HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

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:

  • Big projects tend to move at the speed of the slowest task.
  • 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. [email protected]

    All Rights Reserved
    Copyright ©  2004 SYS-CON Media, Inc.
      E-mail: [email protected]

    Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.