Summary
In a series of predictions for the future of Java EE, Rod Johnson, founder of the Spring project, shares his opinions on de facto versus de jure standards, the role of the JCP, and on why Java EE 6 will usher in renewed app server competition.
Advertisement
As the apparent competition between SpringSource, on the one hand, and JBoss, on the other, heats up, the debate often turns to the question of where enterprise Java is heading. Rod Johnson, founder of the Spring project, shares his predictions on the issue in a recent blog post, The Biggest Loser's Next Contestant: Java Bloatware.
For an alternate view on the subject, Bertrand Emmanuel's SpringSource's strategy is instructive. Emmanuel is a core Hibernate contributor.
Johnson observes that many enterprise Java applications use but a subset of the Java EE specifications. As a result, such projects are often deployed in a simple servlet container, such as Tomcat or Jetty, not in a full-blown Java EE server. While such projects do not require the entire Java EE stack, they, too, would benefit from the management and monitoring capabilities present in full-scale app servers. Thus, writes Johnson, there is a hitherto under-served market for some platform that occupies a place somewhere between Tomcat and, in Johnson's example, WebSphere.
Johnson admits in the blog post that the upcoming Java EE 6 standard's profiles feature addresses that very need: For example, the Java EE Web profile will have just the APIs needed to run a typical Web application, without enterprise integration or Web services components.
Johnson believes that Java EE 6's profiles will result in renewed competition between app server vendors, for the presumed benefit of developers:
We will once more see real competition in the application server space, rather than a continued monopoly of a decreasing number of large vendors. Through version 5, Java EE did not serve the needs of the developers and their organizations so much as the needs of vendors who were protected from competition by the many cumbersome and irrelevant legacy APIs that needed to be implemented by any new entrant...
Tomorrow's application server will have a dramatically smaller footprint than the Jabba the Hut of today.
While Java EE 6 profiles can go a long way in reducing the size of the typical app server, Johnson goes further and suggests that de facto standards are often more useful in real-world applications than the de jure standards expatiated by the JCP:
With the rise of OSGi on the server side and the emergence of SCA, the JCP is no longer the sole source of specifications relevant to enterprise Java. The ubiquity of open source and the emergence of open source de facto standards introduces another element in the mix...
A small number of open source projects are now more relevant to the majority of enterprise Java applications than the majority of the specifications that make up Java EE.
Johnson also predicts that Web applications built on popular open-source frameworks would be best served with a more powerful version of Tomcat:
The majority of Java web applications are most at home on Tomcat. A minority actually want some of the more esoteric functionality of a full-blown application server, such as JCA, or specialized capabilities such as distributed transaction management. But a larger minority need[s] some of the operational and management features of those products, but are not interested in the esoteric APIs and the bloat they bring along with them...
The same underlying platform should be able to address web and SOA requirements.
Do you agree with Johnson's suggestion that de jure standards are more important in many application areas than official JCP standards for Java EE?
> <p>Do you agree with Johnson's suggestion that <em>de > jure</em> standards are more important in many application > areas than official JCP standards for Java EE?</p>
I think you meant <em>de facto</em> here but yes I think this is correct. Noting that OSGi is (as I understand it) an actual standard with specifications, of course.
If you'll allow me to don my tinfoil hat for a moment, it seems to me that a lot of JCP standards seem to be driven by the desire of vendors make money and limit competition. That is, much of the JCP membership is more concerned with driving sales of their products than truly fostering interoperability. Often these standards are needlessly complex and painful to implement.
The trend seems to be that a de facto standard (implemented by any nice open source project) will eventually be integrated into Java or JEE stack often with less powerful and useless API. Compare log4j and JDK logging, Quartz and TimerTasks/Timer beans, Castor and JAXB etc. The good thing about de facto standards is that enhancements and bug fixes are made quickly. With a JCP standard you'd have to wait for the next release of JDK/JEE for a bug fix or an enhancement. Consider for e.g, the NIO classes introduced in JDK 1.4. However the problem with de facto standards is that they can be changed at any time sometimes even breaking backwards compatibility. E.g, Hibernate3 is a LOT different from Hibernate2. So that’s a catch-22.
Regarding "bloatware", which do you consider bloat - the number of APIs or the way the APIs are implemented? Granted not all applications need JMX, JAAS etc but almost all the projects I worked on, needed them (or something like them). I don't see any API that's useless in the JEE stack. But for sure the contracts can be simplified a lot.
Previous Topic
