The Jakarta EE Ambassadors are encouraged by the continued progress and relevance of both Jakarta EE and MicroProfile. We believe a clear, collaborative, and complementary relationship between Jakarta EE and MicroProfile is very important for the Java ecosystem.
Unfortunately the relationship has been unclear to many in the Java community, sometimes appearing to be disconnected, overlapping and competitive. MicroProfile builds on top of some Jakarta EE specifications and many Jakarta EE applications now use MicroProfile APIs. For the success of both, it is imperative that the technology sets clarify alignment to ensure continuity and predictability.
The Cloud Native for Java (CN4J) Alliance was recently formed to address these concerns. The alliance is composed of members from both the Jakarta EE and MicroProfile working groups. The Jakarta EE Ambassadors view this as a positive step. This joint position statement and the additional slide deck linked below summarize what the Jakarta EE Ambassadors would like to see from CN4J as well as the alignment between Jakarta EE and MicroProfile.
We see Jakarta EE and MicroProfile fulfilling distinctly important roles. Jakarta EE will continue to be the stable core for a very broad ecosystem. MicroProfile will continue to strongly focus on microservices, velocity, and innovation. Our perspective on each is as follows:
One major release per year
Targets monolithic applications, microservices and standalone (Java SE/command line) applications – both on premises and on the cloud
Maintains a stronger commitment to backwards compatibility
Enables specifications to be used independently
Enables the ecosystem to build on Jakarta EE technologies, including MicroProfile and Spring
Multiple releases per year
Targets microservices and cloud native applications
Strongly focuses on innovation and velocity including domains such as OpenTelemetry, gRPC, and GraphQL
Depends on core technologies from Jakarta EE
Less stringent requirements on backwards compatibility
It does appear the majority of our community would like to see eventual convergence between the technology sets. It is nonetheless understood this may not be practical in the short term or without its drawbacks. It is also clear that some very mature MicroProfile specifications like Configuration need to be used by Jakarta EE. We believe the best way to meet this need is to move these specifications from MicroProfile to Jakarta EE. The specifications being moved should adopt the jakarta.* namespace. The transition should be a collaborative effort. This is in accordance with what we believe developers have said they want, including through multiple surveys over time.
Jakarta EE also needs to make some significant changes to better serve the needs of MicroProfile and the Java ecosystem. One key aspect of this is enabling specifications to be used independently, including standalone TCKs. Another key aspect is focusing on Jakarta EE Profiles that make the most sense today:
Core Jakarta EE specifications needed by MicroProfile
Some specifications moved from MicroProfile such as Configuration
All Jakarta EE specifications
Deprecate/make optional older technologies
Jakarta EE and MicroProfile are both critical to the continued success of Java. We are committed to working with all key stakeholders towards a strong alignment between these technology sets. We invite all developers to join us in ensuring a bright future for both Jakarta EE and MicroProfile.
The Cloud Native for Java (CN4J) Alliance has recently been formed to promote better alignment between Jakarta EE and MicroProfile.
One of the key issues to sort out is how Jakarta EE can consume MicroProfile specifications (such as MicroProfile Configuration). There are several alternatives as to how this could be done. These alternatives were put into a survey for the community to weigh in. In addition to choosing the option respondents believe to be best, they were able to provide comments justifying their preferred alternative. The results of the survey are summarized here. The results have been shared with the CN4J community and key decision makers.
More than 200 people filled out the survey. Even more remarkably, there were more than 50 comments representing the voice of the community. A fairly strong majority (57.73%) of developers want some MicroProfile specifications to move to Jakarta EE including the namespace.
The results are similar to what earlier surveys have indicated and congruent with the official Jakarta EE Ambassadors joint position. It is remarkable how consistent the community view has been, even over a period of time.
The Voice of the Community
It is impossible to do justice to all the people that provided comments. Each one of the comments is invaluable. The following is a decent sampling representing the majority opinion.
“MicroProfile should evolve APIs that eventually get absorbed by Jakarta EE. MicroProfile applications should eventually be able to run with pure Jakarta EE APIs.”
“Moving MicroProfile specs into Jakarta EE including namespace will make clear where the longer term specs are maintained. Also, for MicroProfile users it’s a very easy migration path.”
“I think no matter which of these options is chosen there is going to be an effect on either end users, or developers. Therefore, I would rather make the large upfront breaking changes all at once and merge the two into the same namespace. Then, have consistency going forward.”
“I would see the movement from org.eclipse.microprofile to the jakarta namespace as a sign of maturity (and success) for MicroProfile.”
“Option A2 has fewer cons and is more end user friendly.”
“Using a different namespace makes it clear what version and expectations (e.g. backward compatibility) the user is making. Moving without a namespace is confusing.”
“The aim of a specification should always be to make something as simple and clear as possible. The entry barriers and opportunities for error for new and inexperienced developers must be as low as possible. An inconsistent namespace or even the possibility of circular dependencies make the use simply too complicated and difficult. At the end of the day, it’s all about the economic and productive development of applications.”
“Move some MicroProfile specifications (e.g. MP Config when its stable) to Jakarta EE including the namespace.”
We really hope the results help pave the way for sensible decisions on Jakarta EE and MicroProfile alignment. For our group, gathering input and listening to people that are not necessarily involved in the lower level details of specification development is extremely important.
The Eclipse Foundation very graciously ran the survey and shared the source data publicly. Reading all the comments in full is especially insightful.
The Cloud Native for Java (CN4J) Alliance has recently been formed to promote better alignment between Jakarta EE and MicroProfile. One of the key issues to sort out is how Jakarta EE can consume MicroProfile specifications (such as MicroProfile Configuration). There are several alternatives as to how this could be done. The following is a brief analysis of the advantages and disadvantages of each approach, as discussed in the CN4J community thus far. At the end of the analysis, there is a survey you should weigh in on. In addition to choosing the option you believe to be best, it is very valuable to provide comments justifying your preferred alternative. The results of the survey will be shared with the CN4J community and key decision makers.
Jakarta EE and MicroProfile Context
Both Jakarta EE and MicroProfile produce specifications that are intended for and used in cloud native and microservices use cases. In particular, MicroProfile has a specific focus on meeting the needs of cloud native and microservices use cases. MicroProfile also produces comparatively faster platform releases (roughly once a quarter) while the Jakarta EE release cadence is slower (the likely long term target being approximately once a year).
Jakarta EE currently provides relatively strong guarantees for backward compatibility for all specifications. MicroProfile does not currently guarantee backwards compatibility for all specifications, but does produce production-ready specifications that have demonstrated real world adoption. This characteristic enables MicroProfile to focus on innovation in emerging areas while Jakarta EE focuses on more conservative use-cases and stability best suited to the largest enterprises. While MicroProfile specifications have on occasion needed to break backwards compatibility, this decision is made with due care for end users.
MicroProfile specifications depend on one or more Jakarta EE specifications while Jakarta EE does not currently have any dependencies on MicroProfile.
Option A1: Move MicroProfile specifications to Jakarta EE without changing namespaces (so no need to change namespace from org.eclipse.microprofile.* to jakarta.*). Nonetheless, the Maven coordinates for MicroProfile specifications will move to Jakarta. Further evolution will take place under the Jakarta EE working group.
There is no need for existing MicroProfile users to switch namespaces.
This gives MicroProfile due credit going forward for bringing a specification into Jakarta EE.
No API duplication between MicroProfile and Jakarta EE.
There is only the existing one-way dependency between MicroProfile and Jakarta EE.
Some users may wish for greater convergence of MicroProfile into Jakarta EE. This option satisfies this desire to some extent.
Lack of namespace consistency for Jakarta EE users otherwise not using MicroProfile.
Some users may perceive this to mean only Jakarta EE is where production ready specifications are available.
It is not immediately obvious to a casual user using both Jakarta EE and MicroProfile in the same application which MicroProfile APIs belong to the MicroProfile working group and which MicroProfile specification belongs to the Jakarta EE working group. This may lead to brand confusion for some users as well as mismatched expectations with regards to characteristics such as backwards compatibility and release cadence.
Option A2: Move MicroProfile specifications to Jakarta EE including the namespace. In this case, the namespaces will be changed from org.eclipse.microprofile.* to jakarta.*. Further evolution will take place under the Jakarta EE working group. No more work will be done in the MicroProfile working group to further evolve a specification once it is moved.
Namespace consistency for Jakarta EE users otherwise not using MicroProfile.
No API duplication between MicroProfile and Jakarta EE.
There is only the existing one-way dependency between MicroProfile and Jakarta EE.
It is immediately obvious to a user using both Jakarta EE and MicroProfile in the same application which specifications belong to the MicroProfile working group and which specifications belong to the Jakarta EE working group. This includes expectations of characteristics such as backwards compatibility and release cadence.
Some users may wish for greater convergence of MicroProfile into Jakarta EE. This option satisfies this desire to some extent. This may include a possible preference for the jakarta.* namespace, which is more generic – as opposed to the org.eclipse.microprofile namespace, which may imply a focus on microservices.
Existing MicroProfile users will need to switch namespaces in order to take advantage of newer versions of moved specifications. Similarly, implementers will need to put effort towards migration, including potentially maintaining two separate work streams at least in the short term.
Some users may perceive this to mean only Jakarta EE is where production ready specifications are available.
Option B: Reference MicroProfile specifications in Jakarta EE and not move MicroProfile specifications. Jakarta EE will not duplicate any referenced specifications and MicroProfile specifications will only be evolved under the MicroProfile working group.
No API duplication between MicroProfile and Jakarta EE.
No migration effort is needed for any users or implementors, while Jakarta EE can still use the specification.
Some users may wish for MicroProfile and Jakarta EE to remain as separate as possible. This option satisfies this desire to some extent.
Lack of namespace consistency for Jakarta EE users otherwise not using MicroProfile.
It is not immediately obvious to a user using both Jakarta EE and MicroProfile in the same application which MicroProfile specifications are referenced by Jakarta EE and which are not (and as a result have different expectations with regards to characteristics such as backwards compatibility).
The referenced MicroProfile specification may wish to break backwards compatibility at some point in its evolution while Jakarta EE does not. Additional efforts will need to be made to address such mismatches.
This introduces a circular dependency between Jakarta EE and MicroProfile. This can make matching release cadences, dependencies, features and collaboration more difficult, including potentially unexpected challenges for end users. The following is one possible example illustrating version dependency mismatches: MicroProfile m2 aligns with Jakarta EE j1, while Jakarta EE j1 aligns with MicroProfile m1. MicroProfile Configuration c2 is included in MicroProfile m2. Jakarta Persistence p1 relies on MicroProfile Configuration c1 in MicroProfile m1 because Jakarta EE j1 was released before MicroProfile m2. An application wants to use both Jakarta EE j1 and MicroProfile m2 together. Which MicroProfile Configuration version will the application end up with? If MicroProfile Configuration c2 in MicroProfile m2 was loaded, Jakarta Persistence p1 may not work with MicroProfile m2 as expected when tested and released via the Jakarta EE j1 compatibility test kit/TCK).
If Jakarta EE integration specific changes are required in MicroProfile specifications, it will require coordination across working groups in a timely fashion with regards to dependencies, release cadence and features.
Option C:Create Jakarta EE versions of MicroProfile specifications. In this case, Jakarta EE and MicroProfile will develop similar features in parallel.
MicroProfile and Jakarta EE can independently evolve features as they best see fit.
End users can mix and match MicroProfile and Jakarta EE as they best see fit. Implementations may do the same.
Duplication of effort and resources across Jakarta EE and MicroProfile. The duplication of effort will likely also extend to implementations.
End users will need to choose between equivalent features in Jakarta EE and MicroProfile.
MicroProfile and Jakarta EE will very likely be seen as directly competing efforts, leading to further confusion.
Voice Your Opinion!
Each of the alignment approaches have advantages and disadvantages. While decision makers might guess what the right tradeoffs for end users and the ecosystem are, you have a role in providing feedback on what works best for you. Please take a moment to fill out this short survey and provide your feedback now. The results of the survey will be shared with decision makers. You should also continue to stay engaged by subscribing to the CN4J Alliance mailing list.
A couple of months ago, the Java EE Guardians group began working with the Eclipse Foundation to go through the effort of changing to a new and more relevant title as the Jakarta EE Ambassadors. We are excited to announce that after much coordination, time, effort, and assistance from the Eclipse Foundation, the rebranding is now complete!
As part of the rebranding, you will notice that the website has been updated to utilize a new URL: https://jakartaee-ambassadors.io and visitors to the old website will be redirected. When visiting the site, you will notice that much work has gone into updating the content and the group now has a new logo. Fellow Jakarta EE Ambassadors are encouraged to use the new logo to proudly associate themselves with the group. Also of note, the group Twitter handle has been renamed to @jee_ambassadors, and the Google Group has been renamed: https://groups.google.com/forum/#!forum/jakartaee-ambassadors.
This is an important time to be a part of the Jakarta EE community. The Jakarta EE working group and community have been working tirelessly to establish the best path forward to Jakarta EE 9. This path includes a major update from the javax.* to the new jakarta.* namespace, cleaning up the release by deprecating older and rarely used APIs, and working to move specifications forward under the new Eclipse Foundation Specification Process. Jakarta EE 9 is on-target to be released later this year.
All of that said, the Jakarta EE ecosystem will need to band together as a strong, unified community and partake in contributing towards making the changes that need to be made to get us to Jakarta EE 9 and beyond. As the Jakarta EE Ambassadors, we should continue to help out, assisting wherever we can, to help move the Jakarta EE platform forward for the entire Java ecosystem. Your role as a Jakarta EE supporter is as important as ever and we urge you to continue to do your part.
Congratulations to all Jakarta EE Ambassadors around the world, and thank you for your efforts!
This post was written by Otavio Santana, a Brazilian Java Champion and SouJava leader.
Java Enterprise Edition (Java EE) is an umbrella with specifications and APIs for enterprise features such as distributed computing and web services. It is implemented by runtimes that can be micro containers or application servers, which handle transactions, security, scalability, concurrency, and management of the components being deployed to it. It has been used widely in Java applications — even if you are a Spring developer, you are using Java EE. Enterprise Java is being standardized under the Eclipse Foundation with the new brand, Jakarta EE. Jakarta EE picks up where Java EE 8 left off, but the road map going forward will be focused on modern innovations such as microservices, modularity, and now, NoSQL databases. To move Jakarta EE forward, the first new specification finished the next step, and it has been approved as an EE4J project. This post will talk about this new specification and the subsequent actions to make the Jakarta EE community even greater.
This end result comes from one year of community work. Thus, there are some posts that explain the top questions about this specification:
Eclipse Enterprise for Java (EE4J) is the top level project in the Eclipse Foundation for all the projects for creating the standards that will form the base for Jakarta EE. The EE4J Project Management Committee (PMC) is responsible for maintaining the overall vision for the top level project. It will set the standards and requirements for releases and help the projects communicate and cooperate.
As a Java developer, I expect a clean process that is focused and community-driven; therefore, a release cadence every three months so that the community can test and provide feedback until the Jakarta EE 9 release. I am aiming for a 1.0 release that looks agile. As with the JCP, there is a life-cycle such as draft and public review.
The first step in Jakarta NoSQL technically is to design the API. The API will have modularity and it will come largely from Eclipse JNoSQL. Thus, Jakarta NoSQL will be the API and TCK while Eclipse JNoSQL will be a reference implementation.
Jakarta NoSQL will use the same approach as Eclipse JNoSQL. In other words, it will have one API for each NoSQL type (key-value, column, document, graph). The mapping will be done through a common API that will have classes that will be shared across all NoSQL databases, including annotations such as Entity, Column, Id and so on.
Jakarta EE has a bright future — it’s open source, contains significant integration abilities, and, most importantly, a community. More transparency, after all, is the most powerful aspect of Jakarta. It’s not the technology itself, but the heart of the community that matters. Therefore, success is ultimately in the hands of ordinary developers. We hope to provide both the technology and the heart on the first new Jakarta specification.
This post was written by Otavio Santana and first appeared here. Otavio is a speaker, Java Champion, SouJava leader and Duke’s Choice Award winner.
The Java EE Guardians have noted with great excitement the final agreement between Oracle and the Eclipse Foundation to move forward Jakarta EE. Eclipse Foundation Executive Director Mike Milinkovich covers the agreement and its objective implications well. He also does a good job outlining current Jakarta EE working group consensus and a high-level view of what is likely to come.
The completion of the agreement opens the door for further critical matters yet to be determined through broad consensus but also establishes some important facts. This is certainly a point that necessitates noting some important observations with regards to advancing the best interests of the Java EE community.
One of the critical decisions that need to be made prior to moving forward is how to proceed with the transition from the javax.* namespace. The Java EE Guardians agree with the consensus of many in the community, as there is a broad desire to move everything to the jakarta.* namespace at once, rather than taking an incremental approach. The Java EE Guardians encourage the community and the Eclipse Foundation to focus on getting a clear consensus about this quickly so that Jakarta EE can confidently evolve with no more delays.
What the Agreement Accomplishes
The reality is that the nature of Java EE and Java as a technology virtually ensures the transfer process would have never fully satisfied everyone all the time. Nevertheless, it is hard not to appreciate the lengthy, complex and undoubtedly sometimes intense effort in reaching the final agreement on the part of both the people at the Eclipse Foundation and Oracle.
In the end Jakarta EE will unfortunately need to stay clear of the Java moniker and further evolution of the APIs cannot take place under the javax* package. However, Jakarta EE will be able to use the Java EE APIs and javax* package as-is and be able to evolve the technology forward under the jakarta* package. This will provide a path forward to further evolve widely relied upon Java EE APIs such as Servlet, JPA, JAX-RS, WebSocket, JMS and so many others. It can also be objectively said the transition from Java EE to Jakarta EE represents one the largest and perhaps most significant technology stewardship transfers ever attempted. This includes not just the agreement but the source code transfer of the Java EE compatibility test kit (TCK) as well as the reference implementation GlassFish.
Where Further Consensus is Needed
The Jakarta EE transfer signifies both great potential and great risk. With the agreement settling some important uncertainties that have been in play for some time, the community must now answer some important questions correctly and in a timely manner.
How quickly should Jakarta EE put the javax* package behind it and how will the transition process look like? Should javax* be gradually replaced by jakarta* or should it be a one-time, immediate transition?
What are the likely contents of Jakarta EE 9 and beyond? Should it be a relatively modest release made available sooner or a more ambitious release beyond 2020?
What is the long- and short-term Jakarta EE alignment with MicroProfile? Which parts of MicroProfile are stable enough to go through a process with clear IP flow to a vendor neutral body, clear participation/consensus rules and rigorous transparency/openness requirements? Which parts of MicroProfile need to forego a more formalized process in order to innovate faster? Does Jakarta EE need a more informal incubation process that does not emphasize microservices in particular but focuses on server-side and cloud needs more generally?
The answers to these questions and the successful execution of the answers will be key to the success of Jakarta EE in meeting community needs. At the bare minimum, these questions must be explored in an open, collaborative and transparent fashion unlike the process of reaching the agreement between Oracle and the Eclipse Foundation where some degree of confidentiality was unavoidable. Indeed, answering these questions requires more than simply a commitment to largely post-hoc transparency within the Jakarta EE working group members.
Listening to the Community
One of the key principles behind the formation of the Java EE Guardians is that Jakarta EE needs to be driven by the needs of the community and the community should actively engage in all parts of the process in developing the technology. Key decision making should focus on who ultimately really matters most – the end user of Jakarta EE. That is definitely the case for the key questions the Jakarta EE effort must now answer.
The Eclipse Foundation has actually already demonstrated it can apply a highly user opinion driven approach to Jakarta EE. Indeed, the name Jakarta EE itself was chosen in a process that emphasized broad participation, user focus and data. The same can be said of the process to choose the Jakarta EE logo. Another encouraging artifact along these same lines are the Jakarta EE surveys the Eclipse Foundation conducted. Indeed prior to Jakarta EE, surveys were used to inform the initial and final scope of Java EE 8.
The Java EE Guardians believe the same open process and spirit can be driven by the Eclipse Foundation to answer the key questions that face the Jakarta EE decision makers today. The Java EE Guardians would gladly volunteer to help drive such an effort. At the current time, the Java EE Guardians have observed that there is a broad desire to move to the jakarta* package scheme as soon as possible as well as strongly align Jakarta EE and MicroProfile, perhaps even merging the projects as soon as is viable.
In the meanwhile, the Java EE Guardians strongly encourage the community to voice its opinion immediately on all these matters on this thread.
The Java EE Guardians are optimistic that a legal framework has finally been agreed upon to move Java EE forward. It is now truly the time to listen to the community and the community to engage wholeheartedly. Indeed the Java EE Guardians will consider renaming themselves to the Jakarta EE Guardians to signify and fully support this bright new chapter for the community and industry.
Adam Bien posted a video Java EE 8 on Java 9 on how to deploy a Java 9 application on Open Liberty using Netbeans. Its a great video and worth a look.
I decided to use the same approach as Adam to deploy a JSF Application on Eclipse Oxygen.
This post deals with installation and the first part of the project installing the core application, the next post will expand on this by building a JSF 2.3 application.
Ensure you are running Java 9 on both classpath and JAVA_HOME, and also ensure you have maven installed.
Open Liberty came from IBM open sourcing WebSphere Liberty, and is a fully compliant Java EE 7 server. They also have an early release Java EE 8 server, which is getting improved all the time in their development builds. We will use a development build for this project, which can be downloaded from here.
Eclipse Oxygen also has a Java 9 release available here – I am using the Java EE version of the Eclipse.
Work through the installation instructions. This is just unzipping Open Liberty Server to your preferred location, and similarly for Eclipse Oxygen.
Start Eclipse Oxygen:
Installing Open Liberty on Eclipse Oxygen
Finally we need to install “IBM Liberty Development Tools for Oxygen” – Help > Eclipse Marketplace.
Then connect up our Open Liberty server on the Servers tab:
Finally point at your Open Liberty deployment location, and ensure you are using Java 9:
You can click finish here.
Finally we need to install the Java EE 8 Feature:
>> Double Click “WebSphere Application Server Liberty”.
>> Click “Open server configuration” then “Feature”.
>> Then “Add…” and select “javaee-8.0”.
I would also remove JSF 2.3 as that’s included in javaee-8.0.
You could start the server now if you want.
The best archetype I have found for Java EE 8 is also from Adam Bien.
Then run maven (right click the project > Run As… > maven install).
Add Project to Open Liberty
Servers > “WebSphere Application Server Liberty” > Right Click “Add and Remove…”.
>> Move our javaee8 application from Available to Configured.
>> Press Finish.
Start Open Liberty
>> Servers > “WebSphere Application Server Liberty” > Right Click “Start”.
You will get an error message about setting a keystore. I am just cancelling this as it is used by the “local connector” feature. I’ve not found a way to clear this error on Eclipse – but will post when I have.
The server will start and you can access the pre-installed application on:
Woohoo running Java 9 on Java EE 8 Open Liberty!!!
This post uses Adam Bien’s approach to running Java 9 on Java EE 8 Open Liberty – but demonstrates how you can integrate this into Eclipse Oxygen. The next post will build on this archetype to create a simple JSF 2.3 application.
Finally I think it is great to see the progress being made to provide Java EE 8 on Java 9, and would like to thank the developers involved in this work.
This post was written by a Martin Farrell, and first appeared Here. Martin Farrel is an independent Java Consultant and trainer based in Edinburgh, UK, with over 18 years Java experience. He has consulted across a range of businesses from banking to telecommunications, and Silicon Valley start-ups. He blogs about Java and Spring technologies on the popular www.javabullets.com blog, and is Most Valuable Blogger at dzone.com and a contributor to javacodegeeks.com.
The results are out and it’s official: Java EE has been retired. This announcement was made by The Eclipse Foundation’s executive director, Mike Milinkovich on his Life at Eclipse blog.
Almost 7,000 people voted in our community poll, and over 64% voted in favor of Jakarta EE.
Goodbye JavaEE, hello Jakarta EE. I was one of the fortunate voters who voted (after a tough thought and decision) on Jakarta EE. Now, I have read responses on Twitter and Reddit that there were only 2 options to choose from (i.e., lack of choice) so let’s have a bit of a history lesson.
How did we get here?
1) The Announcements
On 12 September 2017, David Delabassee announced on the Oracle blog that, along with IBM and RedHat, that:
After careful review, we have selected the Eclipse Foundation as the foundation that we will work with going forward to make the above a reality. The Eclipse Foundation has strong experience and involvement with Java EE and related technologies. This will help us transition Java EE rapidly, create community-friendly processes for evolving the platform, and leverage complementary projects such as MicroProfile. We look forward to this collaboration.
On 15 November 2017, The Eclipse Foundation reached out to the community and the world to “Help Pick the New Name for Java EE” (The primary reason for the name suggestions was due to the Java name copyright. Oracle owns the name Java and now that the project moved to The Eclipse Foundation, they could not have any projects that started with the word Java). Wayne Beaton (Director of Open Source Projects at The Eclipse Foundation) opened up the GitHub issue and the responses were “awesome” (his word). It was in phase 1 that GitHub user, Kenneth J. Jaeger, suggested the name “Jakarta Enterprise Edition”.
3) Brand Name Selection Phase 2: The vote.
On 07 February 2018, the voting was announced for the brand name selection and it began under the EE.next Working group, which is similar to Java Community Process (JCP) with Oracle. The vote ran until the 23 February 2018.
As mentioned on point 2, it was suggested during phase 1 of the name brand selection process. Jakarta (was) an Apache trademark and it has a significant history in contributing to open source Java solutions. Apache Jakarta was retired on 21 December 2011. David Blevins, CEO and Founder of Tomitribe, points out the advantage of the new name Jakarta EE and how Apache Software Foundation have agreed & given the rights to The Eclipse Foundation to use the Jakarta name:
While “Jakarta EE” is not only great because it can be shortened to
“JEE”, referred to simply as “EE” and provides us with a free pass on any acronyms that have “J” in them, it also has room to grow.
The bare word “Jakarta” would be ours and in the future we could create other things under this brand if we wanted. This may include “Jakarta ME”, “Jakarta MicroProfile” or a conference called “JakartaOne.” All of these names roll off the tongue, are instantly familiar and most importantly are community owned and free of any external licensing restrictions.
In the words of Mike Milinkovich:
However, as of today, it is preferred that when you are generically referring to this open source software platform that you call it Jakarta EE rather than EE4J. EE4J, the Eclipse Top-level project, is the only name we’ve had for a couple of months, but as we at least tried to make clear, that was never intended to be the brand name.
So, the terms J2EE and Java EE are no longer valid. It’s a hard pill to swallow but the name is here to stay.
This post was written by a Java EE Guardian, Buhake Sindi, and first appeared here. Buhake is a DevOps engineer, Java & Jakarta EE Developer, Engineer & Consultant with over 12 years of Development experience. He also participates in teaching programming to children through Devoxx4Kids South Africa.
I have a dream: that one day the whole Java community would join forces to strengthen its position on server-side applications where movements such as containerization, microservices, cloud-native or serverless are challenging its paradigms.
As explained in my previous post, Java EE (Enterprise Edition) won’t go beyond version 8 and the future will take a different path under a new name and governance within the Eclipse Enterprise for Java (EE4J) project.
I am entering a dangerous territory on a subject which has often been very polemical but I will try to deal with it with as much objectivity as possible. At my own risk and peril…
Java EE and Spring: a complex relationship
In my impact assessment on the actors of the Java EE ecosystem, I have omitted to mention an indirect but very influential one: Pivotal and more precisely its famous Spring framework.
The relationship between Java EE and Spring has always been rich and complex in “best enemies” mode.
Spring was born in 2004, at the initiative of Rod Johnson, in response to the (real) complexity of J2EE (Java 2 Platform, Enterprise Edition) and in particular that of EJB 2 (Enterprise Java Beans). Since then, Spring and Java EE never stopped competing and influencing each other:
The arrival of Spring (and Hibernate) has caused a beneficial electroshock in the Java EE community which has given birth to EJB 3 and JPA 1, part of a much more approachable Java EE 5 released in 2006,
Spring Batch directly influenced the Batch specification (JSR 352),
Spring Dependency Injection inspired CDI (Context and Dependency Injection),
Spring has always opportunely used the standards from J2EE and Java EE that were of interest to them such as Servlet, JMS, and JPA,
Still today, Spring 5 claims to be compatible with Java EE 8.
Since its creation, Spring has been able to please developers thanks to a pragmatic approach and a very good time-to-market allowing to quickly adopt technological innovations: NoSQL, AMQP, microservices, cloud-native applications…
Since 2006, Java EE has also prioritized simplicity and developer friendliness but with a slower time-to-market due to two main reasons:
The length of time it takes for specifications to be developed within the JCP (Java Community Process): even with a light process, it takes more time to reach an agreement when involving a large number of stakeholders rather than when acting alone,
Implementation and certification time: it often takes several months after a specification release to find supporting and certified Application Servers.
Recently, this gap has widened:
Spring Boot has dramatically increased ease-of-use by pushing the convention over configuration principle to the maximum,
On its side, Java EE has been (much) slower. After a good version 7 released in 2013, a blurry period has set in. In 2016, under the influence of the community, Oracle announced a new Java EE roadmap:
Java EE 8 was released in September 2017, an interesting and highly expected but not revolutionary version. More expectation was put on Java EE 9 in terms of innovation. Except that Java EE 9 will never exist!
In parallel, the Microprofile.io project was launched under the Eclipse Foundation in mid-2016 and gave a new momentum to the Java EE Ecosystem aiming at optimizing Enterprise Java for a microservices architecture. Microprofile 1.0 was based on three specifications representing the least amount of APIs required to build a microservice: JAX-RS 2.0, CDI 1.2 and JSON-P 1.0. MicroProfile 1.2 was released in September 2017 with additional features including Configuration, Fault Tolerance, JWT, Metrics and Health Check. It is expected that version 2.0 will align all APIs to Java EE 8.
Transitioning to EE4J
EE4J aims to offer a more collaborative and responsive way of working. However, the prerequisites for success are not negligible:
Transfer of all Java EE 8 assets (for each specification: documentation, Reference Implementation, and Test Compatibility Kit). This is an ongoing work as explained by David Delabassee,
Implementation of a new governance model and operating system: both flexible and well-organized. A significant step has recently been achieved with the publication of the EE.next working group charter,
Creation and active animation of a community,
Product and package renaming: Oracle does not allow EE4J to reuse the “Java EE” trademark and the javax package (for new specifications). Another name must, therefore, be found. The final vote is open with two options: “Jakarta EE” or “Enterprise Profile”, Even if this renaming is not dramatic in itself, it will require an additional evangelization effort among developers and companies.
Once these elements are in place, EE4J will be able to evolve and adapt to the requirements of cloud-native applications and the changes of the Java SE platform, in particular, Java Platform Module System, which will undoubtedly require a lot of substantial work.
An opportunity for reconciliation?
Beyond governance and technical aspects, EE4J will have to find legitimacy because its status as a standard will disappear outside the scope of the JCP. In this context, EE4J cannot afford the luxury of a fratricidal war against Spring. More broadly, I would say that the overall Java ecosystem cannot afford such luxury. Java’s hegemony for server applications is over and competition is fierce with valuable alternatives such as Node.js, Go, and Python. It would be good to join forces to give a new impetus to bring community and industry together.
Why not? If EE4J delivers a set of independent “à la carte” and compatible specifications,
Spring teams would be able to make specific contributions to those that interest them making then Spring framework a major actor for EE4J.
As developers and users of Java, we all have an interest in it. I have a dream … Will it come true?
This post was written by a Java EE Guardian, Jean-François James, and first appeared here. James is a Software Architect and a JCP Associate Member with more than 30 years of experience in IT and still passionate about it. He is a DevOps advocate who worked on both sides of the “Wall of Confusion”, Head of Worldline France Expert Network and Atos “Distinguished Expert”.
Last Summer, Oracle announced its intention to open source Java EE (Enterprise Edition). This has been confirmed at JavaOne 2017. This article is an attempt to clarify the current status and offer some important perspectives.
According to David Delabassee, Oracle Java EE evangelist, the motivations leading to this decision are to make Java EE more agile and responsive to changing industry and technology demands.
The fact is that the process and the governance model of the JCP (Java Community Process), despite some laudable attempts to make it more open and flexible, was no longer adjusted to the ever faster pace of change of the modern IT market. For instance, so many changes occurred since Java EE 7 (June 2013): a time where NoSQL, containerization, microservices, and serverless were ignored by most of us.
However, in my opinion, this decision was a bit surprising, being in stark contrast with the road map and the commitment announced by Oracle at JavaOne 2016:
At that time, Java EE 8 was being relaunched after several months of inactivity.
Of course, this decision is also an indicator that Java EE is no longer a priority for Oracle. It seems that it prefers to concentrate its effort on a new open source project named Fn, a serverless framework similar to Amazon Lambda and IBM OpenWhisk (now an Apache project).
What’s new with Java EE 8?
It is worth pointing out the effort made by Oracle to deliver Java EE 8 on time (September 2017), not only developing and evolving specifications but also moving Glassfish (the Java EE Reference Implementation) to GitHub.
Java EE 8 main evolutions are:
Java SE 8 alignment: DateTime API, CompetableFuture, repeatable annotations
CDI 2.0: asynchronous events, events ordering, better integration in other specs. With this release, CDI confirms its role of foundation of the Java EE platform
Security: simplification, secret management, modernization, OAuth2 and OpenID support
Overall, Java EE 8 is more a restart that a strong evolution. In particular, the specific ingredients of cloud-native applications are out of its scope: distributed tracing, central configuration, health check, circuit breaker, load balancing.
How is looking Java EE now?
Overall, Java EE remains a valuable platform for most enterprise applications:
the programming model is complete and flexible
one single dependency to rule them all: a typical Maven pom.xml is no more than 20 lines even for complex projects
CDI proves to be easy-to-use and powerful
there is a good integration with most IDE
modern application servers such as TomEE, Payara, Red Hat Wildfly and IBM Liberty are lightweight, offering fast startup and low footprint (Sebastien Daschner clearly demonstrates it in his JavaOne 2016 talk)
In my opinion, the main limitations of Java EE are:
not really at the state of the art: despite its value, most developers do not consider it as a first choice to implement cloud-native applications
lack of overall consistency due to different component models: Servlet, CDI beans, EJB … In particular, the border between CDI and EJB is unclear, this might evolve in the future with CDI taking the role of “first-class citizen”
relative complexity for testing, despite all the good points that I see in Arquillian
the insufficient pace of change both for the specifications and their implementations
not aligned with Java SE: it will take a while before seeing the new Java EE embracing the modularity brought by Java 9.
Evolution of the Java EE Ecosystem
The decision of Oracle has had a huge impact on the whole Java EE Ecosystem, enabling new actors to appear, while strengthening and weakening legacy ones.
Let’s examine the situation.
Oracle is the owner of the Java technology (including EE) and brand. In particular, it remains responsible for Java EE 8 maintenance.
As described below, this ownership poses a serious problem for the branding and the technical content of the future platform since it cannot reuse:
Java EE as a brand name
even the use of Java in a new name is subject to discussion
it cannot reuse the javax package.
Officially defined as “the mechanism for developing standard technical specifications for Java technology”.
The JCP is mostly managed by Oracle: Program Management Office, elections for, votes, management of many specifications …
In terms of organization, the JCP is open. Everybody is welcome to become a member. Companies such as IBM and Red Hat play an important role too.
Java EE is an umbrella specification covering more detailed specifications: Servlet, EJB, CDI, JAX-RS … Until release 8, Java EE was fully within the scope of the JCP.
Each specification is managed in the form of a Java Specification Request (for instance: JSR 366 for Java EE 8, JSR 369 for Servlet 4.0, JSR 365 for CDI 2.0, JSR 370 for CDI 2.1) under the responsibility of an Expert Group following a well-defined lifecycle:
The Expert Group is in charge of three deliverables:
a documentation describing the specification
a Reference Implementation to illustrate the viability of the specification
a Test Compatibility Kit to check the compliance of other implementations.
This is a huge work!
Externally, this process might look heavy at first glance: it takes a while from the initialization of the specification to the delivery of its final release, and it takes another while to have the specification properly implemented by application servers.
Internally, being registered as an Associate Member of the JCP, I must admit that I have been impressed by the quality of the governance model and the commitment of people involved in it. Maybe it was not fast enough, but is innovation the priority for a standard?
A critical aspect of the success of EE4J is its ability to set up a strong while flexible governance model.
Java EE Guardians
Java EE Guardians is “an independent grassroots group of people committed to moving the Java EE platform forward through active community participation and advocacy”.
It has been set up in 2015 (not sure of the date) by Reza Rahman to urge Oracle to restart Java EE 8 which was more or less in the idle state at that time.
Its current focus is on reusing the Java EE brand name and the javax package to ensure a consistent continuity. An open letter has been published early January 2018 for that purpose.
According to its own definition: “The MicroProfile is a baseline platform definition that optimizes Enterprise Java for a microservices architecture and delivers application portability across multiple MicroProfile runtimes”.
Microprofile has been started in summer 2016 and is now an Eclipse project. Its initial contributors were TomiTribe, Red Hat, IBM, and Payara. While not an initial member, Oracle has decided to join it in November 2017.
A first and very pragmatic version was released at JavaOne 2016 based on JAX-RS 2.0, CDI 1.2, and JSON-P 1.0.
Since then, the community has worked on several projects in parallel among which:
The initial ambition of Microprofile.io was to focus on rapid innovation letting the JCP working on standardization. Today, it can also be considered as a “Proof of Concept” for EE4J in terms of community, organization, and governance.
What will be the future of Microprofile.io? Will it merge with EE4J or stay on its own?
According to its charter: “Eclipse Enterprise for Java (EE4J) is an open source initiative to create standard APIs, implementations of those APIs, and technology compatibility kits for Java runtimes that enable development, deployment, and management of server-side and cloud-native applications. EE4J is based on the Java™ Platform, Enterprise Edition (Java EE) standards, and uses Java EE 8 as the baseline for creating new standards.“.
It must be emphasized that EE4J is a project name, not a brand name. A survey has been conducted in Nov. 2017 to select a brand name. Given the restrictions mentioned above, no clear consensus has emerged so far. It seems, that the vast majority (79%) of the community seems to be in favor of keeping Java EE.
A Project Management Committee, made of people already well-known in the Java EE ecosystem, has been set up in Nov. 2017. Its first priorities are the transition, the setup of a new community and the release of a first version based on Java EE 8.
To know more about EE4J status and future go to its FAQ.
Impacts for the Java EE vendors?
Java EE vendors (Red Hat, IBM, Tomitribe and Payara) are enthusiastic about the new situation:
they will have more power and influence that inside the JCP
they will have free access to the Test Compatibility Kits previously owned by Oracle
they will be able to deliver “application servers” in an iterative way without suffering from the next Java EE release “tunnel effect”.
The future of Application Servers
Will the “new Java EE” remain an umbrella specification or a set of independent and consistent specifications?
Corollary question: will Application Servers remain “monolithic platforms” or will they turn into modular and composable platforms?
I opt for the second option as already illustrated today by Red Hat Wildfly Swarm.
Impacts for the developer community?
It may be considered as a good opportunity for the community as a whole to have a more agile and reactive platform making it innovative again.
For individuals, contributing to EE4J can be considered as a springboard to get visibility and influence.
Impacts for the Java EE users?
The current situation is clearly more difficult from a user perspective. The strength of Java EE was its official standard status legitimate by the JCP. Relying on such a standard was of high importance on critical projects with a long lifecycle.
It is clear now that Java EE, in its previous form, has come to an end. Happy or not, we have to cope with it.
The king is dead, long live the king!
What will be the value of the “new Java EE” as a standard? How legitimate will be EE4J without the support of the JCP?
It depends mostly on how fast it will kickoff and provides concrete results. In my humble opinion, the following factors will influence:
Time: as already mentioned, despite its value, Java EE 8 is not considered at the state of art. The gap must be bridged as quickly as possible to come back into the race. It will be very difficult if EE4J spend months to “just” deliver a Java EE 8 compliant version
Synergy with Microprofile.io: Microprofile.io has already started the job to move forward cloud-native applications, let’s leverage it and inject it into EE4J!
Community: how strong and active will be the EE4J community? Who will find interest beyond actors already in place?
Time again: will vendors and Open Source projects be able to deliver on-time EE4J compliant platforms? One of the main issue with Jave EE was the long delay between the final version of the specification and its availability on application servers.
At this stage, I prefer to stay realistically optimistic. So let’s see what will happen in 2018!
This post was written by a Java EE Guardian, Jean-François James, and first appeared on his blog. James is a Software Architect and a JCP Associate Member with more than 30 years of experience in IT and still passionate about it. He is a DevOps advocate who worked on both sides of the “Wall of Confusion”, Head of Worldline France Expert Network and Atos “Distinguished Expert”.