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:
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.