The shifting sands of Java enterprise standards

May 22, 2008

This article was incorrectly linked on its DZone entry, the correct link is given in the comments.

Changes to technology are inevitable and necessary, and some of these changes could affect how your existing applications operate. Such inevitability might make it seem risky to commit to technologies that are driven by changing specifications, such as Java™ EE. However, it is possible to minimize the impact of incompatible changes with informed choices and good planning when determining which technologies are appropriate for you to use.

So, IBM acknowledges that people in the wild are skittish about using the Java enteprise platform, and if you read on in the article you will see why. Some other unstated reasons are the existence of competiting products in Javaland, such as Spring and 1,001 web frameworks, not to mention the Steve Ballmer gorilla called .NET. 

The Java™ EE platform has undergone a number of revisions throughout its history and these revisions have been received as both positive and negative. While most of this change is industry-driven, and therefore desired by the industry at large, there have been revisions that have changed the programming model in "incompatible" ways, including modifications to APIs (potentially causing source compilation problems for existing applications) and behaviors (causing application failures at run time). Understandably, this has caused some degree of angst among those with a heavy investment in applications that are affected by these incompatible changes.

Industry, meaning in no small part, IBM? The company is stating its case in this article to the developer community that the JSR process needs reform. This isn’t new if you’ve kinda followed what’s been happening with Java EE 6 stuff, but I wonder if IBM making working to make its case more publicly with this article:

IBM has been pushing for a change in how technologies are adopted into the Java EE platform; given the maturity of the platform, it is no longer acceptable to adopt new technologies that have the potential of requiring incompatible behavior or API changes in the next release. An incubation period of adoption that lets new technologies mature — or be proven to be mature enough to be adopted into the platform — is strongly desired. Vendors could then choose to offer these incubating technologies with caveats that they could change significantly — and in potentially incompatible ways — in the future. However, once adopted into the platform, these technologies need to evolve in a sane and compatible way. That said, this view is not shared by all the expert group members of the Java EE platform. As a user of the Java EE platform, you are encouraged to make your opinion on this topic known, if you desire a particular outcome. You can do this by contacting the Java EE specification lead or even by contacting the author .

The author then goes into some detail about each part of the Java EE 5 spec and gives IBM’s take on their stability and future direction. IBM is known not to be happy, for instance, with JSR 299, WebBeans.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: