This post has been initially published on my company’s tech blog.
Six months after my post “Where is Java EE going?”, I think it’s time to share an updated status before summer break.
Let’s start with the highlights from my perspective:
- Choice of a new name for the platform in February: Jakarta EE. I must admit that I was not in favour of a new name for the platform, but with hindsight I recognize that it is a good thing to mark the transition: Java EE was one thing and Jakarta EE will be a brand new one!
- Jakarta EE Working Group established in March. This entity will act as the “brain” of Jakarta EE, leading strategic topics such as brand management and the specification process,
- Progressive transfer of the 39 Oracle projects to the Eclipse Foundation under the umbrella of the EE4J (Eclipse Enterprise for Java) top-level project. Kudos to Dmitry Kornilov and his teams for the effort, this is a really challenging!
- Choice of a new logo for the Eclipse Foundation to clearly dissociate its image from its eponymous IDE (Integrated Development Environment) in April. The Eclipse Foundation is now host to about 350 projects spread accross 8 technical tracks: OpenJ9, JNoSQL, Vert.x, Microprofile … And the IDE is just one among others,
- Choice of a (nice) logo for Jakarta EE and opening of the official website at the end of April,
- Upgrade of the Continuous Integration infrastructure for Eclipse Foundation’s projects in April,
- Community meeting at EclipseCon France in Toulouse June 12-13,
- New specification process proposal in June.
An intense activity that shows the progress of the transition and the dynamism of the community.
A few words about the new specification process
The new specification process and its execution will be key to the success of Jakarta EE. The JCP (Java Community Process) has done a great job in that matter during 20 years but has not been able to cope with recent pace of changes. Hence, it was necessary to renew the model.
Here are the main differences compared to the JCP:
- A dedicated gouvernance body: the Jakarta EE Working group,
- Each specification run as a standard Open Source project,
- No specification leader: under the JCP the specification leader had the exclusive ownership of the Intellectual Property which is not acceptable for an Eclipse project,
- No Reference Implementation but at least one Open Source implementation available,
- Free access to the TCK and self-certification,
- Open to non EE4J projects.
This seems a good starting point and I hope to see it executed in a proper way.
What about Microprofile?
Microprofile started mid-2016 as an incubator to feed the JCP. Since then, it has managed to release 6 versions with 5 available implementations. The most recent versions are 1.3 released in January, 1.4 and 2.0 released in June.
Microprofile is a strong asset for the future of Jakarta EE for several reasons:
- It is a demonstrator of how an Open Specification can work,
- It is an Eclipse poject,
- The actors are the same,
- It has prepared everything to turn Jakarta EE into a cloud-native platform.
What is remarkable with Microprofile is the diversity of the discussions and the topics approached: Service Mesh, GraphQL, CQRS/Event Sourcing, Reactive Programming … It fully plays its role of incubator! To get an idea, do not hesitate to visit the Eclipse Microprofile Google group but beware: it is so active that keeping up-to-date is really a big deal!
On a personal basis, I had the chance to be selected as speaker at EclipseCon France to share my user standpoint on this ongoing transition. I also gave a preview of this talk at the Eclipse DemoCamp in Zurich on May 28 (thank you Matthias Zimmerman for the invitation). More recently, I gave it to my company Worldline at its annual TechForum eXplore event in Lille on July 3.
Participating in EclipseCon France gave me the opportunity to meet influential people from the community: Gaël Blondelle, Mickael Barbero from the Eclipse Foundation, Emily Jiang and Kevin Sutter from IBM who are both very active on Microprofile, Ivar Grimstad EE4J PMC lead, James Roper from Lightbend who leads the Microprofile Reactive project, Ondro Mihalyi a well-known speaker from Payara, Dmitry Kornilov from Oracle, without forgetting my friends from Tomitribe: Jean-Louis Monteiro, David Blevins and Amélia Eiras. It was a unique networking opportunity for me. By the way, thanks to Amélia and Simon Chemouil for their friendly company and the atmosphere of the evenings in Toulouse!
During my presentation “From Java EE to Jakarta EE: a user experience”, I try to share my perception on the transitional situation by addressing the following questions:
- Why has the Eclipse Foundation been choosen:
- What are its core values?
- How is it organized?
- What projects are hosted there?
- How to succeed the JCP (Java Community Process) as a standardization body? What makes an open specification under the hospice of an open source foundation valuable today?
- How to setup a new governance model both strong to keep platform consistency and fast to integrate new technologies such as Reactive Programming, NoSQL, GraphQL, Service Mesh,
- Why are non Java EE players such as Lightbend and Microsoft interested in Jakarta EE and MicroProfile?
- How and when can Jakarta EE become a true cloud-native platform?
- How to improve the modularity of Jakarta EE at different levels:
- Specifications: loosely-coupled and highly-consistent,
- APIs and implementations by embracing the Java Platform Module System,
- Application servers: “just enough runtime” is the new norm and there is no longer room for bloatted and monolithic application servers!
- How to cope with the new Java SE release cadence with two feature releases per year and 1 Long Term Support every 3 years?
My message is simple: the story does not end with Oracle stopping Java EE development, a promising future is possible with Jakarta EE, an open and vendor independant specification. However, all is not won and the next two years will be decisive. As a user, you have a role to play! Each contribution even modest will be welcome.
Beyond the content of my presentation, I’ve observed that it is difficult to draw developers’ attention to Jakarta EE. It seems that over the past 2 years, developers’ concerns have shifted. Influenced by the DevOps movement and the generalization of Cloud platforms, pure development issues seem to have become less critical in the eyes of developers than packaging and deployment issues. In particular, mastering Docker and Kubernetes has become a high priority and there is little room left for a new specification challenging well-established solutions such as Node.js and Spring Cloud.
A challenge for Jakarta EE will therefore be to be identified as a credible and easy-to-use cloud-native solution.
Several conditions must be reached to achieve this:
- An approriate communication:
- That renews the image of Java EE (too often perceived as a legacy solution),
- Which targets a wider audience than the historical Java EE user base,
- Which clearly explains the values and scope of the Eclipse Foundation beyond its IDE,
- An efficient roadmap execution that supports the transition from Java EE to Jakarta EE and the transformation into a cloud-native platform,
- Availibilty of both free and commercial implementations to suit the strategy of companies and the needs of projects,
- Productive development tools like Spring Initializr and JHipster. Generally speaking, getting into the developer’s shoes to offer him the best development experience,
- High quality trainings available to company’s workforce,
- Last but not least, a good execution of the new specification process to find (and keep) the right balance between platform stability and innovation. Careful: hell is in the details!
In other words, Jakarta EE must move beyond the promise stage and quickly become a reality. The end of 2018 and the beginning of 2019 will be decisive in this respect.
And remember, as users we also have a role to play in this success!
That being said, I wish a good summer break to everybody!
Leave a Reply