Transitioning Jakarta EE to the “jakarta” namespace

As described in Jakarta Going Forward, we need to transition the Jakarta EE specifications to the jakarta.* namespace/base package. After long and intense discussions in the Jakarta EE Specification, we have proposed two possible ways forward to kick-start the discussions on this thread.

In this post, I am highlighting some of the content of the initial post to the mailing list for reference.

Proposal 1: Big-bang Jakarta EE 9, Jakarta EE 10 New Features

The heart of this proposal is to do a one-time move of API source from the javax.* namespace to the jakarta.* namespace with the primary goal of not prolonging industry cost and pain associated with the transition.

https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html

Proposal 2: Incremental Change in Jakarta EE 9 and beyond

Evolve API source from javax.* to the jakarta.* namespace over time on an as-needed basis. The most active specifications would immediately move in Jakarta EE 9. Every Jakarta EE release, starting with version 10 and beyond may involve some javax.* to jakarta.* namespace transition.

https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html

Other Proposals

Other proposals should incorporate the following considerations and goals:

The new namespace will be jakarta.*

APIs moved to the jakarta.* namespace maintain class names and method signatures compatible with equivalent class names and method signatures in the javax.* namespace.

Even a small maintenance change to an API would require a javax.* to jakarta.* change of that entire specification. Examples include:
– Adding a value to an enum
– Overriding/adding a method signature
– Adding default methods in interfaces
– Compensating for Java language changes

Binary compatibility for existing applications in the javax.* namespace is an agreed goal by the majority of existing vendors in the Jakarta EE Working Group and would be a priority in their products. However, there is a strong desire not to deter new implementers of the jakarta.* namespace from entering the ecosystem by requiring they also implement an equivalent javax.* legacy API.

There is no intention to change Jakarta EE 8 goals or timeline.

Community discussion on how to transition to the jakarta.* namespace will conclude Sunday, June 9th, 2019.

https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html

Contribute

There are already a lot of contributions and lively discussions going on. Please make sure you join the Jakarta EE Platform Developer Discussions mailing list https://accounts.eclipse.org/mailing-list/jakartaee-platform-dev to take part in the conversation. At the time of writing this post, the number of subscribers to the list has more than doubled! Another proof of the passion and commitment in the Jakarta EE community!

Jakarta Going Forward

The agreement between the Eclipse Foundation and Oracle regarding rights to Java trademarks has been signed! This is truly an important milestone for Jakarta EE since we will now be able to move forward with Jakarta EE.

As outlined in https://eclipse-foundation.blog/jakarta-ee-java-trademarks, there are two major areas of impact on the Jakarta EE projects:

  • Java Trademarks
  • The javax.* Namespace

Java Trademarks

One part of the agreement is regarding the use of Java trademarks. The implications for Jakarta EE is that we have to rename the specifications and the specification projects. This work is ongoing and is tracked in our specification renaming board on GitHub. The EE4J PMC has published the following Naming Standard for Jakarta EE Specifications in order to comply with the trademark agreement.

The javax Namespace

The major topic of the agreement is around the use of the javax namespace. The agreement permits Jakarta EE specifications to use the javax namespace as is only. Changes to the API must be made in another namespace.

While the name changes can be considered cosmetic changes, the restrictions on the use of the javax.* namespace come with some technical challenges. For example, how are we going to preserve backwards compatibility for applications written using the javax.* namespace?

The Jakarta EE Specifications Committee has come up with the following guiding principle for Jakarta EE.next:

Maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.

With the restrictions on the use of the javax.* namespace, it is necessary to transition the Jakarta EE specifications to a new namespace. The Jakarta EE Specification Committee has decided that the new namespace will be jakarta.*.

How and when this transition should happen is now the primary decision for the Jakarta EE community to make. There are several possible ways forward and the forum for these discussions is the Jakarta EE Platform mailing list.

Mailing List: jakartaee-platform-dev@eclipse.org

Please make sure that you subscribe to the mailing list and join in on the discussion. We hope that we will be able to reach some form of consensus within a month that can be presented to the Specification Committee for approval.

An Opportunity

While the restrictions on the use of Java trademarks and the javax.* namespace impose both practical as well as technical challenges, it is also an opportunity to perform some housekeeping.

By renaming the specifications, we can get a uniform, homogeneous naming structure for the specifications that makes more sense and is easier on the tongue than the existing. By having clear and concise names, we may even get rid of the need for abbreviations and acronyms.

The shift from javax.* to jakarta.* opens up for the possibility to differentiate the stable (or legacy) specifications that have played their role from the ones currently being developed.

What’s in a Name?

As Wayne Beaton wrote about in his blog Renaming Java EE Specifications for Jakarta EE, the process of renaming the Java EE specifications as a part of the path towards Jakarta EE 8 has started.

Naming is hard and changing names that we have become attached to is even harder. Most of us also have this inherent feeling that change is bad and should be avoided. At the same time, we live in this ever-changing industry where embracing change is, not only a mantra but also a requirement to survive. Add to this, that some of the names we are talking about in this context are pretty bad. Some of them so long that we have to google the acronym to be able to describe what it actually abbreviates. Some of the acronyms we are using daily aren’t even acronyms, but more of an artificially created letter combination following some sort of standard. A couple of examples:

Jakarta Authentication

I think most of us agree that Jakarta Authentication is far more easy to remember than The Java Authentication Service Provider Interface for Containers. It may not be as precise and descriptive, but should that really be the requirement of the name? Wouldn’t it be better to have a name that we can remember and use in daily talk?

Jakarta REST

Think about Jakarta REST versus Java™ API for RESTful Web Services. I don’t think anyone ever uses the long name, but rather the abbreviation/acronym JAX-RS. Which isn’t even an acronym! It is just some collection of letters to fit into the JAX-* naming standard used by Sun back in the J2EE days.

Jakarta Messaging

The Java™ Message Service specification covers create, send receive and read messages. So it is much more than just a message service. In this case, Jakarta Messaging would be a much more descriptive name.

Participate!

We have created an issue in each of the specification GitHub projects as well as a Specification Project Renaming board in EE4J GitHub organization to track the process.

Please join the discussion by commenting on the issue related to the particular specification you are interested in. If you are the first commenting on an issue, please move it to the In Progress column. I will try to keep the status updated, but all help is welcome.

Final Thoughts

I am positive to renaming the specifications even if it is a lot of work and may seem like an unnecessary use of resources. It is an opportunity to fix something to the better in one go and this is probably the perfect time to do it.

Jakarta EE 8 Status

Those of you following Jakarta EE probably know that the upcoming Jakarta EE 8 release will be functionally equivalent to Java EE 8. The reason for this is that we want to prove that the transfer from Oracle is complete and that we are able to produce the processes, specifications, test suites and a compatible implementation through the Eclipse Foundation.

So far Eclipse GlassFish 5.1 has been released and certified as Java EE 8 compatible. The next step is to set everything up for Jakarta EE 8 and release Eclipse GlassFish 5.2 as Jakarta EE 8 compatible.

One of the tasks that need to be done in order to release Jakarta EE 8 is to transform the existing Java EE specification documents to Jakarta EE. This will involve renaming the specifications according to the trademark agreement between Oracle and Eclipse Foundation*.

In addition to this, the scope for the existing EE4J projects containing the APIs for the individual specs will need to be updated and the projects themselves will be converted into Jakarta EE specification projects as defined in the Eclipse Foundation Specification Process (EFSP). The Jakarta EE Specification process will be a specialization of the EFSP.

To keep track of all of this, we have created a planning board in the Jakarta EE Platform GitHub project.

Planning board for transitioning Java EE 8 specifications to Jakarta EE 8
Planning board for transforming the Java EE specification to Jakarta EE

What I have described in this post is just a couple of the things that need to be done regarding the specifications in order to get Jakarta EE 8 out the door. There are a lot of other activities involving the TCK and not the least Eclipse GlassFish 5.2 that need to be done as well. But for now, the most critical item is to get through the legal hurdles of the trademark agreement and the transfer of the specification documents over to Eclipse Foundation.

*) The details of this agreement is yet to be defined when this blog post is published.

Jakarta EE Developer Survey 2019

The Jakarta EE 2019 Developer Survey is available!

Take the survey today and help the community gain a better understanding of what’s in store for Java innovation. This is your chance to share your thoughts and experiences and help shape the future for Jakarta EE!

Jakarta EE 2019 Developer Survey
https://www.surveymonkey.com/r/JakartaEEMkt

Responses will be collected until March 25, 2019, at 11:59 PM Pacific Time

JCP Star Spec Lead 2018

Wow, what a year 2018 was for the MVC specification!

I know we are well into 2019 now and that I did sum up 2018 in early January. In that post, I mentioned that Christian and I received the JCP Outstanding Spec Lead Award at the JCP party for our work on JSR 371. At the same ceremony, Daniel Dias Dos Santos received the Outstanding Adopt-a-JSR Participant Award, also for his work on JSR 371.

And to top it all, Christian and I were announced as 2018 Star Spec Leads. Read more about the Star Spec Lead Program. 

A complete list of all Star Spec Leads can be found in the Star Spec Lead Hall of fame.

Have You Tried the MicroProfile Starter Yet?

The SPRING INITIALIZR at https://start.spring.io has been around for a while and is the best way to bootstrap a new Spring Boot application.

So far, there hasn’t been a similar way to bootstrap a new MicroProfile project even if the different vendors have provided starters for their implementations. But the wait is over! The MicroProfile Starter is currently in “Beta”, but works like a charm. Just navigate to https://start.microprofile.io and start generating.

https://start.microprofile.io

Based on which version of MicroProfile you select, you will get the available implementations that supports that particular version. You have the option of generating examples for the specifications included in the selected version. This is an excellent way to learn how the different technologies work.

#OSSRRR at Devnexus 2019

Devnexus 2019

Devnexus 2019 is happening in Atlanta next month. This is truly an awesome tech conference run by the Atlanta Java Users Group and I am so happy to be part of it as a speaker for the third time.

My talk this year is a presentation of patterns commonly used in microservice architectures. Each of the patterns will be explained and demoed live using Eclipse MicroProfile.

Microservice patterns in Eclipse Microprofile

Another think I look forward to at Devnexus is to meet up with will all the people participating in Jakarta EE that are present at the conference.

The party theme this year is R3, which stand for Reflect, Relax, Recharge and is definitely the place to be to meet all the awesome community members, Java Champions and Groundbreaker Ambassadors present! Everybody will be there, and so should YOU!

There is a limited number of super cool t-shirts exclusively made for this party. One of them could be yours simply by writing a blog post!

Java Community Process Update

The Java™ Community Process has been updated through JSR 387: Streamline the JCP Program. The most significant change is to open up for Iterative JSRs, i.e. JSRs that intend to deliver multiple releases of a technology on a time-based cadence. The driving force for this change is the 6 month release cadence for Java™ SE.

The first JSR using the option for being iterable is JSR 388: Java™ SE 13 (I guess the JSR name will have to be changed to not include the version number…).

Another change made in this update where changes to reviews and ballots in order to make the process even lighter to accommodate shorter release cycles.

The™ Java Community Process

Amazon Corretto 8

UPDATE! I have updated the option of running Corretto in Docker to using the amazoncorretto Docker image available from Docker Hub.

Amazon Corretto is a production-ready distribution of OpenJDK with long-term support including performance- and security updates provided by Amazon.

Tweet announcing Amazon Coretto 8

Amazon provides installation packages and instructions for Linux, Windows, and macOS, as well as a Docker. The latest installation package is based on OpenJDK version 1.8.0_202:

If you don’t want to, or isn’t able to install Corretto on your workstation, t is pretty straightforward to try it out using Docker:

Amazon Corretto is licensed under the same license as OpenJDK (GPLv2 with CPE) and there are no costs associated with using it. Amazon will provide quarterly security updates to Corretto 8 at least until June 2023.

But Java 8 is sooo old!

Relax, Amazon plans to make Corretto 11 available during the first half of 2019. Corretto 11 will be based on OpenJDK 11.