Life at Eclipse

Summary of progress to date and implications of the agreement between Eclipse and Oracle on Jakarta EE and use of Java trademarks and the javax namespace.

Introduction

The migration of Java EE to the Eclipse Foundation has been an enormous effort on behalf of the Eclipse Foundation staff and the many contributors, committers, members, and stakeholders that are participating.

This post was reviewed and represents the consensus view of the Jakarta EE Steering Committee.

Earlier this year GlassFish 5.1 was certified at Eclipse using the Java EE 8 TCK at the Eclipse Foundation. Since then under the direction of the working group the community established a Jakarta EE Specification Process (JESP) for the evolution of the Jakarta EE specs at the Eclipse Foundation. Specification projects are being created for all of the Jakarta EE specifications. The TCK process is being refined for Jakarta EE in concert with the new Jakarta EE compatibility logo. This is all being done in support of the Jakarta EE 8 release.

Progress to Date

The Jakarta community has been busy.

• Oracle contributed GlassFish and the Java EE APIs and TCKs to Jakarta EE.
• The Jakarta EE Working Group was formed and supporting committees to provide governance to the community and facilitate collaboration.
• Eclipse GlassFish was certified with the Java EE TCK at the Eclipse Foundation.
• The Eclipse Foundation Specification Process was created, and customization created and approved for the Jakarta EE Specification Process.
• Specification projects are being created and work is underway now within the community to deliver the Jakarta EE 8 release later this year.
• There is an initiative underway for Oracle, IBM, Red Hat and other members of the JCP to contribute their specification documents created at the JCP to Jakarta.

It had been the mutual intention of the Eclipse Foundation and Oracle to agree to terms that would allow the evolution of the javax package namespace in Jakarta EE specifications.   Unfortunately, following many months of good-faith negotiations, the Eclipse Foundation and Oracle have been unable to agree on terms of an agreement for the Eclipse Foundation community to modify the javax package namespace or to use the Java trademarks currently used in Java EE specifications.   Instead, Eclipse and Oracle have agreed that the javax package namespace cannot be evolved by the Jakarta EE community. As well, Java trademarks such as the existing specification names cannot be used by Jakarta EE specifications.  Because of the complexity and confidential nature of our negotiations, the Eclipse Foundation and Oracle have also agreed that we will not attempt to characterize here what has resulted in this outcome. It is the best outcome we could mutually achieve for the community. Some additional context is provided in the Eclipse Foundation Board and Jakarta EE Steering Committee meeting minutes.

What restrictions does this outcome impose on the Eclipse community?

Oracle’s Java trademarks are the property of Oracle and the Eclipse Foundation has no rights to use them.   The implications of this are as follows:

1. The javax package namespace may be used within Jakarta EE specifications but may be used “as is” only.  No modification to the javax package namespace is permitted within Jakarta EE component specifications. Jakarta EE specifications that continue to use the javax package namespace must remain TCK compatible with the corresponding Java EE specifications.
2. Jakarta EE component specifications using the javax package namespace may be omitted entirely from future Jakarta EE Platform specifications.
3. Specification names must be changed from a “Java EE” naming convention to a “Jakarta EE” naming convention.  This includes acronyms such as EJB, JPA or JAX-RS.

In addition to the above, any specifications which use the javax namespace will continue to carry the certification and container requirements which Java EE has had in the past. I.e., implementations which claim compliance with any version of the Jakarta EE specifications using the javax namespace must test on and distribute containers which embed certified Java SE implementations licensed by Oracle. These restrictions do not apply to Jakarta EE specifications which do not utilize javax, including future revisions of the platform specifications which eliminate javax.

Note that the ratified Jakarta EE specifications will be available under a different license (the Eclipse Foundation Specification License). This is the reason why the Eclipse Foundation is currently asking the community to update their contributor and committer agreements.

What is next for the Jakarta EE Working Group?

The Jakarta EE Working Group including Oracle will continue to do what they set out to do: namely, move Java EE to the Eclipse Foundation. The group remains committed to creating a Jakarta EE 8 specification, logoed under the Eclipse Foundation’s Jakarta trademark. Further, the group is also committed to future versions of the Jakarta EE specifications that deliver on the original promises of innovation and evolution in cloud-native Java.

What does it mean for Jakarta EE to not modify the javax package namespace?

The Agreement does allow for modification and evolution under a new namespace, such as jakarta. It is expected that all future evolution and innovation will not use the javax namespace.

What happens to the Jakarta EE brand?

The Jakarta EE compatibility and the Jakarta EE member logos have both been decided on by the community and published. Work is underway to deliver the branding usage guidelines and supporting trademark license agreement. We expect to see the usage of these brands later this year.

Will there be a Jakarta EE 8?

Yes. The community is working hard to deliver the Jakarta EE 8 release, which is Java EE 8 delivered from Eclipse. We expect that many application servers will certify as Jakarta EE 8 compatible.

What happens beyond Jakarta EE 8?

The guiding principle for Jakarta EE 9 will be to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.  This will most likely involve two key topics: migration of some or all of the Jakarta EE specification source to a new namespace for future evolution; means to provide backwards compatibility with javax at a binary level, allowing old applications to run on Jakarta 9 implementations with some form of build or runtime tooling.

So while there will be a point in time where future versions of specifications will have to go through a source code incompatible change with respect to the previous javax based packages, this will be a straightforward transformation.

Further plans are being evolved by the Jakarta EE community via the Jakarta EE Platform Project. Your comments and participation are encouraged.

What does this mean for the EE4J projects?

The specification projects need to be renamed to not use Oracle’s Java trademarks. The Jakarta community gets to decide on the new names. This is an opportunity to tighten up the naming and get a better level of consistency. The future of Eclipse Enterprise for Java (EE4J) projects will be determined by the community who participate in those specifications and open source projects.

What is next for Eclipse GlassFish?

Work is underway at the Eclipse GlassFish project running the Jakarta EE 8 TCK and being ready to support its role in the TCK for interop testing. The future of Eclipse GlassFish will be determined by the community who participate in the project.

How will specs be updated beyond Jakarta EE 8?

Jakarta EE specifications will be updated according to the approved Jakarta EE Specification Process (JESP). The actual enhancements will be determined by the community who participate in those specification projects.