Of course, these are just plans for now. There are many questions unanswered and I don’t want to join the speculations here. However, here are some thoughts and hopes from my side.
As you might know, I’m quite involved in Java Enterprise technology. I work a lot in this area, offering consultation and workshops to my clients. I’m also involved in two JSR Expert Groups, JAX-RS 2.1 and JSON-P 1.1, both being part of Java EE 8.
I totally confirm that there is a lot of interest and value in this technology, so I saw this news with great excitement.
First of all, it must be mentioned that it is a very positive step that Oracle informed the Java (EE) community early about its plans. By the way, my personal opinion is that Oracle, in general, is currently moving in a very positive, interesting direction: for example, opening their database to Docker this year, contributing to open-source cloud-native technologies such as Kubernetes, and so on and so forth. This is great — hopefully, we see more open source in this world.
It was also very positive to mention that Java EE 8 will continue as is. There has been a lot of effort involved here lately from all the JCP members, Expert Groups, and people working on GlassFish. These efforts will make it into a Java EE 8. This is very positive for me also since I’m currently writing a book on modern enterprise application development with Java EE. Java EE 8 will ship as expected, so I don’t have to delete or rename things in my current work!
Oracle believes that “a more open process, that is not dependent on a single vendor […] will encourage greater participation and innovation” Yes, I totally agree. As we know as computer scientists, singletons don’t scale.
Moving contribution to an open-source foundation can certainly bring a lot of chances in moving the technology forward. This especially touches the point that a single corporation does not have to provide all the effort to run a process like this. The current process behind Java EE surely depends a lot on Oracle's workforce.
In my opinion, the biggest value in Java EE is the standardized APIs — all the individual ones together under the umbrella. These provide great benefits not only for companies that can rely on standard, backward-compatible technology, but also for developers who are familiar with the APIs and use them in their daily work. It is great to that the APIs can live on and continue to being evolved. This is especially interesting in regards to licensing, TCKs, and RIs, where the IP always was an issue.
If I was to express my hopes and wishes for Java EE, I would love to see the technology continuing in a similar way as it is today with more possibilities to contribute.
The relevance of enterprise standards is certainly there. I would like to preserve the nature of Java EE, in terms of standardized, backward-compatible technology that engineers can rely upon and that is combined under an umbrella. Or even better, several umbrellas, or profiles, that contain certain sets of standards.
Today’s fast-moving world certainly asks for processes being more agile and flexible, which needs to be addressed in order to make Java EE stay relevant in the future. Opening up Java EE targets this. Still, I think that EE should stay a standard technology in the enterprise, providing the backward-compatibility and reliability as we know it. Enterprise standards should continue to carve in stone what has proven itself well in other, faster-moving, flexible technology.
I also think that the way Expert Groups operate is something that should be continued under a new possible foundation. The CDI EG is one of the best examples for this. It has always been very active and very open for feedback, questions, and contributions from outside of the JCP. Everyone is invited to join discussions and ongoing development. Still, it is organized as a committee of experts.
The Java EE umbrella specification with its profiles is a very interesting approach. It’s very beneficial for developers and companies to rely on standards “being there” and working together seamlessly. Still, today’s world could sometimes need profiles that require the implementation to contain fewer, less heavy parts. I would love to see a similar formation as today’s Java EE 8 specification containing several reasonable profiles that match more of today’s demands. See the MicroProfile initiative as an example.
I’m super excited to see what’s next for Java EE. This certainly will be an interesting JavaOne conference this year.
I would love to see the nature of Java EE continuing — also see why I’m using Java EE. It’s definitely good for the enterprise standards and APIs being able to continue.
Still, an interesting question will be what this means for the JCP as we currently know it. Interesting times ahead.