Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Update on Jakarta EE Rights to Java Trademarks

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.


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.

Written by Mike Milinkovich

May 3, 2019 at 6:00 am

20 Responses

Subscribe to comments with RSS.

  1. Excellent. Now, let’s go forward!


    May 3, 2019 at 9:42 am

  2. We should simply have forked years ago, the outcome would have been the same, but we wouldn’t have lost years. I do not see what actually Oracle now allows us more than any other fork.

    Markus KARG

    May 3, 2019 at 12:06 pm

    • That’s is simply incorrect.

      First off, Oracle open sourced the TCKs at Eclipse. That’s huge, and would not have happened anywhere else.

      Secondly, Oracle is licensing their copyrights in all of the specifications to the Eclipse Foundation. Also, huge.

      Thirdly, Oracle, IBM, Red Hat and others are participating in the Jakarta EE specification process moving forward, thus licensing their relevant patents to these specifications.

      None of those are true of other possible forks. All are extremely important to the value of this community and ecosystem going forward.

      Mike Milinkovich

      May 3, 2019 at 12:25 pm

      • I do not share your view. First, the TCK is of no real use for non-Oracle coders, as it is a technical nightmare monolith; it will be easier to write new TCKs for some of the APIs than trying to overhaul the existing ones. Second, the specifications cannot be published unless all authors agree, so de facto as of today they are useless, too; it might be easier to write new specifications than to wait for the day the last author signed an agreement. Third, whether or not Oracle, IBM and Red Hat participate in Jakarta EE was not part of the trademarks negotiation with Oracle at all; this is part of different agreements. The actual result, renaming everything, including acronyms and package names, is the worst that could have happened. I don’t know how to see anything good in the outcome besides the fact that the waiting is over.

        Markus Karg

        May 3, 2019 at 1:19 pm

      • +1 on your assessment & view !

        Viktor Ransmayr

        May 3, 2019 at 3:27 pm

  3. Mhhh, renaming javax.* to jakarta.* should be very straight forward for me. Maybe there will be also a sed-script for this. Really, i don’t see a big problem here. A posible breaker could be reflective access on javax.-classes. I hope that not so many libriaries are affected. JDK 11 with not accessible JDK internals makes much more trouble.



    May 3, 2019 at 3:27 pm

    • Yup. And you’ve touched on a couple of reasons why it likely makes more sense to switch *everything* from javax to jakarta at once, rather than attempting some sort of iterative migration.

      Mike Milinkovich

      May 3, 2019 at 5:08 pm

  4. Sad to see 9 people decide the fate of a programming language loved & used by millions of passionate developers. These things are not giving good vibes.


    May 3, 2019 at 6:06 pm

  5. […] on Jakarta EE Rights to Java Trademarks EE has landed EE 8 and […]

  6. […] Update on Jakarta EE Rights to Java Trademarks – so Jakarta EE can’t use or change anything in the javax package namespace, which might have an impact on seamless transition from Java EE to Jakarta EE. But Jakarta EE is still very much alive and relevant. […]

  7. […] also ist offiziell die (einvernehmliche) Entscheidung getroffen worden, dass die Eclipse Foundation keinerlei Rechte […]

  8. […] like to thank the community for the level of engagement we’ve seen in response to my post from last week.   This post, which again represents the consensus view of the Jakarta EE Steering […]

  9. […] Update on Jakarta EE Rights to Java Trademarks […]

  10. […] The announcement that Jakarta EE can not use the javax.* namespace is nice information and offers Jakarta EE with a clear slate on which to construct and innovate the way forward for Enterprise Java. […]

  11. […] zusammengefasst. Alles Wesentliche zum Hintergrund, warum javax ausgedient hat, gibt es im Blog-Beitrag von Mike Milinkovich und hier auf […]

  12. […] EE will not be allowed to evolve APIs in the javax.* namespace. (See Mike Milinkovich’s announcement and his followup Twitter thread.) Shortly thereafter, David Blevins posted a proposal and call for […]

  13. […] schlechte Nachricht kam Anfang des Monats. In einem ausführlichen Blog-Post teilte Mike Milinkovich, geschäftsführender Direktor der Eclipse Foundation, der Community mit, […]

  14. […] 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 […]

Comments are closed.

%d bloggers like this: