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.
This article attempts to explain how you can minimize your exposure to incompatible changes in the Java EE platform and how IBM® tries to minimize the impact of these changes to your organization.
Sources of incompatibility
There are several sources of incompatibility that can get introduced into the platform. The best that can be said is that the members of the expert groups involved in refining the specifications generally try to do the right thing, but, as humans, we are not perfect. No matter how hard we try, there will always be something that slips through:
The first source of incompatibility is lack of fully specifying all behaviors. Fully specifying all behaviors is really an impossible task and would require omnipotence on the part of the expert group members to predict every interpretation of the specification text (as well as extensions) that vendors might introduce. The result can lead to portability issues when moving an application between vendors, and can also cause problems in later revisions of the specification as the extended behaviors become fully specified standard behaviors.
A slightly related issue is lack of full testing of compliance to the specification. The Java EE Compliance Test Suite (CTS) is intended to ensure correct behavior according to the specification. However, it does not fully test all the requirements. In some cases, it is not possible to create a test case. In others, resource constraints might prevent implementing all the required test cases. In still others, the test case might be eliminated from the test suite because the test case doesn't work properly. Any vendor could pass the CTS and not recognize that their software behaves differently than the specification requires. Later additions of test cases to the CTS might surface the problem, requiring a change of behavior after the product is already in the field. In addition, vendors might pass the CTS, behave properly (as they interpret the spec), but still act differently than other implementations (as another implementation might make different assumptions). In these cases, clarifications to the specification are needed (and typically made in maintenance releases). These specification updates might require a change of behavior in a product that is already out in the field to take on the new interpretation.
Another source of incompatibility is accelerated technology adoption into the platform due to emerging technologies. One example we've seen of accelerated delivery is JAX-RPC. This was an attempt to rapidly deliver a set of APIs to handle the rapidly growing industry need for Web services. However, the emergence of best practices and usage patterns showed that the APIs (as they were originally defined) could have been defined much more efficiently, and that it was better to entirely revise that technology stack in order to provide a better set of APIs.
A similar case is the accelerated adoption of the J2EE™ deployment model. The original version of this technology was found to be woefully deficient in handling application deployment and was never really adopted by the industry. Luckily, very few users did adopt this particular platform technology and so most would not be impacted by its removal or replacement.
A third source of incompatibility is lack of recognition of the problem itself. Although the expert groups are made up of industry experts in the area that is being addressed by a specification, there are cases where incompatibilities have either not been recognized or have not been a concern. Expert groups work toward collective goals, but keep in mind that each expert group member also has his or her own objectives, which might not always align with (or take into consideration) the needs of every individual user of the platform.
Fourth in the list of incompatibility sources is lack of resources dedicated to ensuring compatibility. It is possible for Java EE platform vendors to provide better assurance of compatibility by providing test efforts and reporting back on problems that were encountered. However, this requires that vendors have working implementations of the specifications during their draft phases, which has proven to be somewhat impractical.
IBM hears the complaints about incompatible changes and attempts to address them wherever possible. Starting with the Java EE 5 specification, IBM fought hard for the specification to remain backward compatible (both binary and source). Sun™ has always maintained a notion of binary compatibility for Java, but IBM recognized that source compatibility was also important for application serviceability. As a result, specification leads are now including compatibility statements in the specifications.
Of course, it is nearly impossible to fully specify all behavior. IBM participates in many of the expert groups and provides feedback on many specifications where we have identified problems. In some cases, we have been able to head off compatibility problems we have recognized, and in other cases, we have not.
One example of success has been the freezing of JAX-RPC and a new specification (JAX-WS) being opened as its successor, thereby preventing incompatible changes to JAX-RPC. This won't change the long term need to migrate to a current API, but it will prevent the short term requirement for that. Freezing a specification enables you to recognize when a given set of APIs are viewed as non-strategic, but it will not affect the behavior of your existing applications that you might have built using that technology. Preservation of customer investment is one of the priority objectives that IBM attempts to achieve by participating in standards.
This brings up the issue of deprecation. IBM attempts to recognize and preserve legacy behaviors and APIs and provide support for them beyond what the specifications require. At some point, IBM declares the legacy behavior or API as "deprecated," which identifies an intention to remove the behavior or API in the future. Generally, this designation provides two full IBM product release cycles of support before the deprecated behavior is removed.
One recent example of where we were not successful in identifying incompatibilities early is with interpretation differences of the specification with regard to transaction propagation requirements for Web components. This is a case that has existed since very early in the servlet specification. The specification will be clarified to make users aware that dependencies on this behavior will likely be non-portable. (It is not clear yet whether or not it will affect IBM WebSphere® Application Server behavior.)
Rapid adoption of technology can be both good and bad. On the good side, it addresses needs of the industry in a timely manner. On the bad side, it can "bake-in" problems that might otherwise have been identified with the benefit of a bit more experience. 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.
There has been an increase in recognizing of the importance of compatibility since IBM began campaigning for it. More and more expert group members are starting to get serious about compatibility issues, and the specifications are getting more explicit about the compatibility intent of the specification. This is not to imply that incompatible changes won't be made; only that the specification lead and the expert group might be more apt to consider the implications before deciding to make incompatible changes. These situations will generally be documented so that users of the specification will know this up front.
As of yet, not everyone is convinced that source compatibility is just as important as binary compatibility. For well architected technologies, interfaces can evolve and not require source code changes. Others have little choice except to make incompatible changes if they want or need to evolve. IBM tries to ensure that technologies are well architected, but the industry needs to help keep an eye on everything. The specifications go through a draft stage so that the industry -- you -- can provide feedback.
Possible user mitigations
Beyond what IBM is doing, there are a number of things that you can do to provide some mitigation against the potential for incompatible change:
Get involved in the specification process. It never hurts to have more eyes on the changes that are being made -- and it ensures that your issues get heard. The Java EE 6 specifications are currently undergoing revision and will soon be available in draft form. That will be a perfect time your you to look for changes that could impact your existing applications and assess the impact if those changes were to be approved.
Depend only on stable specifications or parts of specifications. For example, the basic servlet specification has been around (and fairly solid) for a long time. Servlet filters have been around far less. JAX-WS services are brand new. It is reasonable to expect that the newer the technology or functional addition, the more likely it is to change in incompatible ways.
Keep an eye on industry trends. If there's a hot topic in the industry, it's likely to be an evolving story. Web services and SOA are hot topics right now and the technology to support them is likely to change with time. Whether or not they remain compatible during this evolution will be up to the industry as a whole, although IBM will do its best to ensure that it does.
Java EE technologies, present and future
The remainder of this article looks at specific technologies included in the Java EE platform and their expectation for change:
Servlets should be a fairly stable technology at this point, mature and fairly well understood. Other than addressing Web 2.0, there are no significant changes expected. Of course, that's not to say that there won't be any changes:
Java EE 5 addressed some of the usability problems in the platform by permitting metadata to be embedded in component source code. The servlet specification did not take full advantage of this and so it is expected to do so. However, this should only add additional forms of metadata rather than changing any behavior.
Another major change in Java EE 5 is the integration of the expression language between JavaServer™ Faces and JavaServer Pages, but this integration was designed to be backward compatible and should present no major issues.
One possible future change is metadata scopes. Servlets tend to declare metadata at a module level and share it among all Web components. EJBs tend to declare metadata at the component level. This is expected to evolve to enable both component and module scoped forms of metadata. Again, this is not expected to cause any incompatibility as the existing scope behavior should be maintained.
Another possible area of change is adding programmatic APIs to dynamically define behavior rather than defining it declaratively. SOA seems to be pushing this style and it is likely that all technologies will adopt both a declarative and programmatic behavior model at some point, if they haven't already. For the most part, this should not cause any incompatibility. The only possible exception would be adding methods to interfaces that must be implemented by applications. Given the current trend in the industry of getting away from explicit interfaces (and using annotated methods instead), this is not expected to be an issue.
- JavaServer Pages (JSP) and Java Standard Tag Library (JSTL)
JSPs and JSTL are also fairly stable technologies at this point, with no significant changes expected.
- JavaServer Faces (JSF)
JSF is still a relatively new technology. JSF is undergoing a major revision for the next round of specifications with an expected integration between JSF managed beans and Enterprise JavaBeans™. The risk of changes affecting existing applications will be higher here than with other presentation technologies. IBM does have representation on the JSF expert group and will keep a watchful eye out for problems.
One area of future concern is be how well Ajax support in JSF will follow the specifications for the OpenAjax Alliance. Through its participation, IBM will try to ensure that compatibility is maintained as the standards move forward. Ajax support in JSF will be new (when it appears) and use of that feature will be at a somewhat higher risk than other parts of JSF. More details will be known in early 2009.
Although not part of the Java EE platform, IBM WebSphere Application Server V6.1 and later provides the ability to utilize portlets. The portlet specification is currently undergoing a revision, but IBM is the specification lead and has a level of control over its evolution.
Version 2.0 of the portlet specification is a major revision that adds features omitted in Version 1.0, like coordination of resource serving, and leads the Java Portlet specification toward a path of maturity. Changes likely for later versions will mainly be to align with changes in other Java EE specifications, such as Servlet 3.0 or JSF 2.0, but they are not likely to include major new functionality on the portlet side.
At the time of this writing, Version 2.0 of the Java Portlet specification appeared to be source and binary compatible to Version 1.0, and switches were to be added for controlling underspecified Version 1.0 behavior that is now specified in Version 2.0. This compatibility assertion will be validated once the specification is finalized and sufficient testing has been performed.
- Enterprise JavaBeans (EJB)
The EJB specifications have added new capabilities over time, but have done so in an upward-compatible way. The EJB 3.0 specification changed the EJB programming model syntax in a fairly dramatic way. However, the older 2.1 and prior programming models are still available, and even the 3.0 programming model contains backward compatibility support, enabling clients and server components to be implemented with different versions of the specifications.
Session beans are fairly stable at this point and no substantial behavior changes are expected, although new functions are likely to be added.
Message-driven beans are also fairly stable.
CMP/BMP persistence is stable, but is likely to be deprecated in favor of Java Persistence APIs (JPA) as a relational persistence technology, or the Java EE Connector Architecture (JCA) for non-relational persistence.
One possible change that might affect this in the next round of specifications is the potential to bring session and message-driven beans together, into a single component style with both synchronous and asynchronous interaction styles. Given the last revision of the specification, it is reasonable to expect sane and compatible evolution here as well.
JDBC is quite stable at this point, offering a good long term investment in performance and compatibility, assuming you do not change your database vendor; a database vendor change might require changes in the SQL statements or in the locking and isolation levels you use.
- Java Persistence APIs (JPA)
JPA is the technology slated to replace EJB CMP Object/Relational Mapping support in the Java platform. This is a new technology and so further evolution is expected. However, it is also based on multiple vendor implementation experiences (Hibernate, TopLink, and Kodo) and therefore the risk of change causing incompatibilities is somewhat reduced. JPA provides some isolation from JDBC vendor differences.
- Java Message Service (JMS)
JMS has changed little in a long time and is considered a stable technology.
- Java EE Connector Architecture
The Java EE Connector Architecture has been stable for some time, but has some issues that will be addressed in the next round of specifications. The current architecture does not address failover or inbound and outbound consistency; vendors have had to rely on extensions to handle these issues. Changes in the specification to address these and other problems are planned to be compatible, but could eventually affect custom-written resource adapters. Adapters purchased and maintained from other vendors should hide any affects (if any) of those changes.
- JavaMail and JavaBeans Activation Framework (JAF)
JavaMail's evolution has been somewhat quiet, possibly because there is a smaller percentage of developers using it than, say, servlets or EJBs. This architecture tends to have more implementation classes that could be affected by evolution, making it more difficult to evolve and maintain source compatibility. However, in general, it appears to be mostly stable at this point and no changes are currently foreseen. JAF is used for MIME type handling and is generally considered as stable as JavaMail.
- Java API for XML-based RPC (JAX-RPC)
JAX-RPC is likely to be deprecated in Java EE 6, and therefore any new development needs to consider the option of using:
- JAX RPC: a technology that is stable, but does not work for all cases and will be going away, or
- JAX-WS: a new technology that is likely to change, but is a reflection of where the industry is moving.
- Java API for XML Web Services (JAX-WS)
JAX-WS is the second generation of a Web services API, taking strategic precedence over JAX-RPC. It was defined as a new technology in order to avoid backward compatibility issues that would have hampered the evolution of the specification. There have already been some issues around the evolution of JAX-WS, due to decisions of the W3C standards committees, that have led to revisions removing the support of some requirements of the specification. The Web services area is likely to evolve even more. Currently, there is a desire to standardize the qualities of service related to a Web service (such as reliable messaging or transactions), in addition to a focus on RESTful Web services (via JAX-RS – JSR 311). All of this is still relatively new and shakeouts are likely to occur as the industry gains more experience in these areas.
From a maturity perspective, JAX-WS has benefited greatly from the JAX-RPC experience. The lessons learned from JAX-RPC and fed into JAX-WS have produced a reasonably effective and mature specification. The inclusion of both JAX-WS and JAXB in Java SE 6 (the JDK/JRE) will likely stabilize these technologies even further.
- Java Architecture for XML Binding (JAXB)
JAXB is also new, but similarly evolved from the previous JAXB 1.0 delivery. Combining that experience with leveraging input from JAX-RPC and JAXB's inclusion into JAX-WS, JAXB is better positioned in its second release (like JAX-WS is over JAX-RPC) to be a stable and compatible technology. While it maintains the same name as its predecessor, its implementation and much of what it is trying to accomplish has been rewritten based on lessons learned from its past deficiencies. It could evolve further as the platform tries to address more consistent mappings between Java objects and other representations, such as protocol marshalling or persistence. Expectations are that backward compatibility will be maintained for those mappings.
- SOAP with Attachments API for Java (SAAJ)
SAAJ is a fairly stable rendering form for Web service messages. Apart from its extension of leveraging standardized DOM APIs, it has undergone little change since its initial release.
- Java API for XML Registries (JAXR)
JAXR is another technology that was introduced and adopted by the Java EE platform too rapidly. JAXR was based on providing an abstraction over UDDI V2 and ebXML V2, but V3 versions of those standards were produced almost simultaneously, rendering JAXR somewhat obsolete out of the gate. The industry is still evolving in this space somewhat, so any further evolution of JAXR is also likely to be out of date when complete. Once the industry settles down a bit, JAXR will likely either evolve dramatically or be replaced by another technology.
- Java EE Management
Java EE Management has been fairly stable and its stability is expected to continue.
- Java EE Deployment
This technology should be avoided, as it is insufficient for the task and is likely to go away or be replaced by a substantial revision in the future.
- Java Authentication and Authorization Service (JAAS)
JAAS provides the core of security services for the Java EE platform. It is generally stable, but there are known differences in behavior across vendors regarding JAAS subject propagation. This will attempt to be clarified in a future Java EE platform specification so that industry consistency may be achieved.
- Java Authorization Contract for Containers (JACC)
The changes in Java EE 5, enabling metadata declarations via annotations, have required changes to JACC to enable the handling of annotated security declarations. JACC 1.0 providers are not likely to be able to provide appropriate security behavior with security annotations in use, although existing applications that do not use annotated security declarations should continue to run fine.
Of course, the future is uncertain, but you can expect some technologies to continue influencing the Java EE platform. The technologies listed below should be approached with caution from a compatibility standpoint, since it is likely that they will evolve dramatically.
- JAX-RS - RESTful services
The industry has recognized that it is not always efficient to have a formal Web service for loosely coupled services. However, this is new for the industry and not a lot of experience has been built up yet around this hot topic. As best practice patterns emerge, it can easily be imagined that the specification could change dramatically.
The Java EE 6 content proposal includes the addition of a new technology called WebBeans. Originally proposed as a way to integrate JSF managed beans and EJBs, it has since evolved into a distinct component model meant to encompass many other component models. There is very little experience in this space (although WebBeans was intended to be modeled on JBoss Seam, it has gone well beyond that experience). The closest example might be to look at the years of deliberation that went into producing the first SCA specification, which also serves as a component model that encompasses many other component models. Unless the scope of WebBeans is reduced dramatically in the near future, its specification is likely to evolve dramatically.
- Timer and Workmanager
These specifications drive enterprise qualities of service into asynchronous (that is, threaded) programming styles. They are based on joint work done by IBM and BEA (CommonJ) and have somewhat reduced risk based on multiple vendors having delivered these technologies, but these specifications have rebased the API on the Java Concurrency Utilities for threaded work management. It remains to be seen whether the industry will accept this or require additional changes, but the risk of their use is likely to be smaller than WebBeans. Using existing Asyncronous Beans APIs within WebSphere Application Server will provide the best long term stability and compatibility -- at least until these specifications stabilize.
There is no crystal ball for determining whether to use a specific technology or functional aspect of the Java EE platform. The industry is ever evolving and that has an effect on the platform. However, it is possible to make informed choices when determining which technologies are appropriate to use, and hopefully the information in this article provided enough information to help you make those informed choices.
The author thanks Dana Duffield, Greg Truty, Kevin Sutter, Maxim Moldenhauer, Piotr Przybylski, Randy Schnier, Stefan Hepper, and Stephen Kenna for their contributions.