Java EE Configuration JSR Deferred
Java EE Configuration JSR Deferred
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
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, 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 quite 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 we 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.
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 rich set of configuration and conditional build focused Maven features such as profilesand replacers.
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.
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.
Published at DZone with permission of Reza Rahman , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.