Configuration was one of the more popular items on the Java EE 8 survey. While the exact features that would be included in a configuration JSR for Java EE remains relatively vague, I think we were all looking forward to a possible JSR largely spearheaded by Anatole Tresch of Credit Suisse. The idea was that such a JSR would provide a cohesive solution for configuring Java EE applications and would receive a level of support from Oracle, including possibly sharing responsibility for leading the specification. Unfortunately the configuration JSR effort has currently been deferred for unforeseen but unavoidable circumstances principally related to long-term resourcing commitments especially for developing and maintaining the associated reference implementation (RI) as well as the compatibility test kit (TCK).
This is truly unfortunate as this would have been a shining example of a non-Java EE vendor (in this case Credit Suisse) contributing a significant part of the Java EE platform. It is still important to applaud Anatole Tresch for his initiative, passion, dedication and courage. Similarly the community should be grateful to Credit Suisse for seriously considering such a significant investment to help move the Java EE platform and community forward. As all of us in IT know, making tough calls on resourcing is never easy and it is far better to make difficult decisions early rather than at later stages of an effort. Anatole is still moving forward with his JavaOne 2014 talk on the configuration JSR effort. The talk is a great opportunity to share ideas and solidify underlying use cases through community feedback. This thought provoking post alludes to some of the complex uncertainties that this JSR would need to carefully explore.
While a cohesive configuration JSR effort must be deferred at least for now, there is no reason to dismay too much. Some of the more well-understood problems that such as JSR would have solved could still be considered as part of the Java EE 8 platform JSR. A separate JSR would have likely required a high degree of collaboration at the platform level anyway. Another possibility is to have core APIs like CDI consider what needs to be done to make configuration easier in Java EE. Lastly, it's worth keeping in mind that some of the problems that such as JSR would have addressed may already be solvable using mechanisms included in Java EE or with tools that are commonly used in Java EE development such as:
- Using the <alt-dd> tag that has been included in Java EE for a while.
- CDI @Alternative.
- JSF project stages.
- The configuration centric features included in DeltaSpike Core. The mature Apache Commons Configuration project has had similar capabilities for a while, albeit more focused on look-up (rather than injection) and Java SE (rather than Java EE).
- The rich set of configuration and conditional build focused Maven features such as profiles and replacers (this really isn't anything specific to Maven, most emerging or mainstream build systems have such capabilities for good reasons).
In my own personal experience as a consultant I have found the Maven features in particular a sufficient, easy-to-use and elegant solution for the vast majority of Java EE projects. That being said the distinction for the configuration JSR might have been that while Maven is a build-time solution, there is perhaps a need to solve configuration issues at deployment-time or at run-time. One should note though that while dependent upon non-standard tooling many modern application servers do support changing JNDI bindings at runtime.
What do you think? As always, don't hesitate to sound off here.
Please note that any views expressed here are my own only and certainly does not reflect the position of Oracle as a company.
