About two years ago, thousands of Java developers attended the JavaOne 2015 conference and learned about specifications and features that would be part of the Java EE 8 platform. These features included the MVC 1.0 specification, Java EE Security 1.0, Microservices, CDI and more. Java EE 8 was shaping up to be a great follow-up to the excellent Java EE 7 release.
After JavaOne 2015, progress and news around Java EE went silent. In early January 2016, I received an invite to a Slack group that was created by some members of the Java EE community. On the Slack channel, there were discussions around the halt of Java EE, and what the community may be able to do in order to keep it moving forward. I was humbled by the sense of community from the members of the channel and the devotion to the platform was very evident. Not long after, the Java EE Guardians were formed, focusing on publicizing the stall of Java EE. The group put forth effort pressuring Oracle to make a statement and continue moving Java EE forward. Especially in this fast paced space, looming silence regarding the future of any technology can be taxing on those involved. Others worked on the Java EE specifications as much as possible, making strides forward.
After almost a year of silence, we started to hear music around Java EE again, and at JavaOne 2016 Oracle unveiled the plan to continue moving Java EE 8 forward, albeit a bit differently than originally planned. The newly envisioned Java EE centered around Microservices and dropped a few of the specifications that no longer fit into the puzzle. MVC 1.0, JMS 2.1, and Management 2.0 were taken out of the picture, while the newly proposed Health Checking and Configuration APIs were added. MVC was eventually handed over to the community, which I think was a great move. The Health Checking and Configuration APIs, which were clearly aimed toward microservices support, were later taken out of the picture for Java EE 8 due to lack of time. Java EE 8 had more community involvement than any previous Java EE release, and much of this is likely due to the hiatus. Java EE 8 moves forward, albeit a bit more lean than originally planned, we are moving forward.
Now, nearing the JavaOne 2017 conference, we are on the heels of a Java EE 8 release. This release includes much of the original core Java EE 8 plan, bringing the Java EE platform in-line with Java SE 8. It also enhances CDI support throughout the specifications, brings forth Security 1.0, which is long overdue, and JSON-B, closing the JSON to Java conversion gap that was left after JSON-P was released. Java EE 8 will be a solid release, and I am thankful to all who are involved in making it happen. I am sorry to say that I will not be at the JavaOne conference this year when it will likely be released, but I know that my colleagues will keep me in-tune with the latest news coming from the conference! If you are going, make sure you check out the many great Java EE talks that will be presented.
Almost like a professional sports superstar going out on a high note, Oracle recently announced that they are planning to open source Java EE. I have to applaud Oracle for all of the great work they've done and the support that they've given to Java EE through the years. I am hopeful that they will remain engaged even after Java EE is open sourced, as they are a very important player in this space. In my mind, they chose a perfect time to announce the opening of Java EE, as the Java EE 8 release will mark a great milestone making Java EE even more productive and relevant as one of the top application development platforms in the industry. The community around Java EE seems as though it has never been more engaged than it is now. Over the years since the cumbersome J2EE morphed into the productive platform that we call Java EE today, the community has continued to grow by the thousands. The Java EE Guardians have thousands of supporters, each of them hoping to help move Java EE forward for years to come.
I see a great future for an open Java EE. However, many questions are left to be answered. Will the JCP still be used to manage the changes that are proposed for the platform? Perhaps this is one of the questions that has the potential to impact the platform the most. If the JCP will still be used to manage the platform, can it be changed in such a way that it will be conducive to a faster moving platform? Do we want Java EE to become a faster moving platform, much to the likes of other frameworks such as Spring?
One of the main strongholds of Java EE is standardization. If the open Java EE were to become more dynamic, can it maintain its place as a standard in the industry? I think so. I think that ideally the JCP could still be used to move the specifications forward, with a bit of a modernizing on the approach. I like the idea of having shorter Java EE release cycles with fewer changes in each release. Such an approach can really help the platform to retain its relevancy in this fast moving space.
What are your thoughts on the opening of Java EE? I welcome it and look forward to seeing what is to come for JavaOne 2018.