Moving Forward with Oracle and Eclipse Foundation Agreement on Jakarta EE

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.

Java 9 on Java EE 8 Using Eclipse and Open Liberty

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.


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

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:


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:


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 blog, and is Most Valuable Blogger at and a contributor to

Where is Java EE going?

This post was written by Jean-François James, a Java EE Guardian .

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:

Java EE roadmap as of JaveOne 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
  • Servlet 4.0: HTTP/2 support (Server Push)
  • JAX-RS 2.1: Server-Sent Event, reactive extensions
  • JSON Processing 1.1 and JSON Binding 1.0
  • 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)
  • as explained by Adam Bien, even if not perfect, developing containerized microservices with Java EE is a valid option.

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:

  1. documentation describing the specification
  2. Reference Implementation to illustrate the viability of the specification
  3. 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:

  • microprofile-config
  • microprofile-fault-tolerance
  • microprofile-health
  • microprofile-metrics
  • microprofile-open-api
  • microprofile-jwt-auth

The initial ambition of 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 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.

For now, two projects are officially part of EE4J:

  1. Yasson: the Reference Implementation of JSON-B,
  2. EclipseLink: the Reference Implementation of JPA.

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:

  1. 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
  2. Synergy with has already started the job to move forward cloud-native applications, let’s leverage it and inject it into EE4J!
  3. Community: how strong and active will be the EE4J community? Who will find interest beyond actors already in place?
  4. 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!

Stay tuned with EE4J user mailing list and EE4J PMC mailing list.

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

Joint Community Open Letter on Java EE Naming and Packaging

Oracle has promised to open up the ownership of Java EE by moving it to the Eclipse Foundation via the EE4J project. This is a tremendously positive move that will make a very important part of the overall Java platform truly open and agile.

The problem is that Oracle wants to restrict the use of the word “Java” and the use of the “javax” packages for EE4J due to corporate branding concerns. This is forcing a rename of Java EE and the use of another package for new Java EE technologies. We believe this desire is not aligned with the best interests of the community and the industry. This may indeed also be true of Oracle’s own business interests as Java EE is moved further in the direction of microservices, the cloud and serverless computing.

The clearest evidence that the current direction to rename and repackage Java EE is wrongheaded is community opinion. When asked, developers overwhelmingly support keeping the Java EE name and “javax” packages (#1, #2). These preferences are so strong they have remained unchanged for several months even despite current declared EE4J plans.


There are several sensible reasons these preferences make sense:

  • Java EE remains a strong brand with developers. In industry survey after survey, developers make it clear they value Java EE.
  • While no name is perfect, Java EE is a very suitable name for the platform. This has become especially apparent as the community has struggled repeatedly to come up with a sensible new name.
  • The renaming of the platform from J2EE to Java EE causes continued market confusion even over a decade after the renaming. A further renaming of the platform will likely only add to the confusion. This includes the existence of pervasive resources referring to the Java EE name and javax packages. It will be unclear for a long time how these resources relate to a rebranded platform.
  • Java EE should be and is seen as an integral part of the overall official Java open standard platform. This distinction is important and uniquely valuable to users, contributors, implementors and supporters of Java EE. Any new name that does not prominently feature Java will diminish this value. The problem applies even more so to a packaging scheme other than “javax”.
  • A new platform in which a significant portion of APIs belong in the “javax” package while another significant portion of APIs belong in another package is confusing and inelegant.
  • Stability, backwards-compatibility and continuity are key characteristics Java EE adopters have valued for a long time. A forced rebranding can be perceived to be undermining these valuable characteristics.

All of these factors will likely stand in the way of the rapid success of a new platform with a new name and new package structure. Indeed these factors – particularly a perceived lack of continuity – may even negatively impact adoption of existing Java EE technologies.

On behalf of the community, the Java EE Guardians ask that Oracle and other EE4J stakeholders work together to allow the new platform to retain the Java EE name, the “javax.enterprise” package for new technologies and existing “javax” packages for existing technologies.

There are many ways these goals could be accomplished. The following are just a few obvious possibilities.

  • Oracle can license the Java EE name to the Eclipse Foundation. The license can allow limited use of the “javax.enterprise” package for new technologies, limited use of the “javax” packages for existing technologies but still allow Oracle to retain control over the rest of the “javax” package for non-Java EE technologies. If needed Oracle can separately trademark the Java EE brand from the Java brand. Such an action is not without precedent. Sun Microsystems licenced the “JavaScript” trademark to Netscape. Allowing a limited license to the Eclipse Foundation would not diminish the Java brand at all. Indeed, similar to JavaScript, allowing for Java EE to be opened up will only enhance the Java brand, much like the C# brand being enhanced by Microsoft choosing to standardize it through the ISO/ECMA independent standards organizations.
  • While naming is a very important concern, retaining the “javax/javax.enterprise” packages is even more important. One way this could be easily accomplished is still standardizing EE4J technologies though the JCP. The relationship between EE4J and the JCP could be very similar to the relationship between OpenJDK and the JCP. While most work can happen in EE4J, the JCP could be used as a passthrough standardization mechanism. The recent faster release cadence for Java SE through the JCP proves that agility is not the major concern in the JCP. The downside of the approach is that Oracle and other EE4J stakeholders would need to work together to resolve mutual concerns over the JCP.

The Java EE Guardians sincerely hope Oracle and EE4J stakeholders listen to and adequately address community concerns. It must be noted that even if the naming and packaging issues are not properly resolved, timely forward movement of the EE4J initiative is still in the best interests of the community.

The Java EE Guardians stand behind the EE4J initiative even despite the fact that failing to properly resolve the naming and packaging issues will pose significant challenges to an already daunting effort.

The Java EE Guardians are a joint community of many Java Champions, Java User Groups, Java User Group leaders, JCP experts, JCP members, open source committers, authors, bloggers, speakers and ordinary Java developers around the world.