Today the Jakarta EE Ambassadors are announcing the start of the Jakarta EE Community Acceptance (JCAT) Testing initiative. The purpose of this initiative is to test Jakarta EE 9/9.1 implementations testing using your code and/or applications. Although Jakarta EE is extensively tested by the TCK, container specific tests, and QA, the purpose of JCAT is for developers to test the implementations.

Jakarta EE 9/9.1 did not introduce any new features. In Jakarta EE 9 the APIs changed from javax to jakarta. Jakarta EE 9.1 raised the supported floor to Java 11 for compatible implementations. So what are we testing?

• Testing individual spec implementations standalone with the new namespace. 
• Deploying existing Java EE/Jakarta EE applications to EE 9/9.1.
• Converting Java EE/Jakarta EE applications to the new namespace.
• Running applications on Java 11 (Jakarta EE 9.1)

Participating in this initiative is easy:

1. Download a Jakarta EE implementation:
   1. Java 8 / Jakarta EE 9 Containers
   2. Java 11+ / Jakarta EE 9.1 Containers
2. Deploy code:
   1. Port or run your existing Jakarta EE application
   2. Test out a feature using a starter template

To join this initiative, please take a moment to fill-out the form:

 Sign-up Form 

To submit results or feedback on your experiences with Jakarta EE 9/9.1:

  Jakarta EE 9 / 9.1 Feedback Form

Resources:

• Jakarta EE Ambassadors Google Group List
• Jakarta EE Amabassors Twitter
• Jakarta EE Starter
• Jakarta EE 9 Boilerplate
• Jakarta EE Migration

Start Date: July 28, 2021

End Date: December 31st, 2021

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:

Jakarta EE

• 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

MicroProfile

• 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 Profile

• Core Jakarta EE specifications needed by MicroProfile
• Some specifications moved from MicroProfile such as Configuration
• CDI Lite

Full Profile

• 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.

Additional Material

• Jakarta EE/MicroProfile alignment slide deck
• Jakarta EE/MicroProfile alignment survey results

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.

Pro:

• 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.

Con: 

• 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.

Pro: 

• 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.

Con: 

• 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.

Pro:

• 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.

Con:

• 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.

Pro:

• 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.

Con: 

• 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!

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.

This post was originally written by Martin Farrell.

I wrote a post a few weeks ago titled Which IDEs and Servers support Java EE 8 and Java 9 which looked at the current state of play between Java 9 and Java EE 8. As you would expect things have moved quickly and we now have some alpha and development builds of Open Liberty supporting Java 9 and Java EE 8.

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.

Installation

Java 9

Ensure you are running Java 9 on both classpath and JAVA_HOME, and also ensure you have maven installed.

Open Liberty

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

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.

First Project

The best archetype I have found for Java EE 8 is also from Adam Bien.

To run it simply type:

mvn archetype:generate -DinteractiveMode=false -DarchetypeGroupId=com.airhacks -DarchetypeArtifactId=javaee8-essentials-archetype -DarchetypeVersion=0.0.2 -DgroupId=com.javabullets.javaee8 -DartifactId=javaee8

Then let’s compile straight away and make sure there are no errors:

E:\code\javaee8>mvn clean package

Note the archetype is compiled against Java 8, we will move it to Java 9 in the next section.

The source code is available at https://github.com/farrelmr/javaee8.

Open in Eclipse

In “Enterprise Explorer” select:

Import > Import… > Maven > Existing Maven Projects.

Navigate to your Java EE 8 directory, click Finish and let Eclipse load your project into Eclipse.

Open the pom.xml file and change source and target from 1.8 to 1.9:

<properties>
    <maven.compiler.source>1.9</maven.compiler.source>
    <maven.compiler.target>1.9</maven.compiler.target>
    <failOnMissingWebXml>false</failOnMissingWebXml>
</properties>

Then run maven (right click the project > Run As… > maven install).

Add Project to Open Liberty

Go to:

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:

http://localhost:9080/javaee8/resources/ping

Woohoo running Java 9 on Java EE 8 Open Liberty!!!

Conclusion

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.