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

Eclipse GlassFish 5.1 is here!

The release of Eclipse GlassFish 5.1 is an important milestone for Jakarta EE!

First of all, it is a confirmation that the GlassFish source code contributed by Oracle is possible to build and assemble on Eclipse Infrastructure.

Second, by passing the Java EE 8 Compatibility tests, it verifies that the code contributed follows the Java EE 8 specifications, hence is Java EE 8 Compatible.

Download Eclipse GlassFish 5.1 and give it a try!

And while you’re at it, why don’t you try it out with Apache NetBeans as I have shown below.

Eclipse GlassFish 5.1 in Apache NetBeans 10

2018 Annual Summary

It’s this time of the year again. Time for the yearly summary of conferences, travels, community activities, open source projects, amazing people!

Like most recent years, I have been speaking at quite a few conferences around the World. The countries I visited as a speaker in 2018 were Sweden, Germany, USA, England, Denmark, France, Belgium, South Africa, Australia, and New Zealand.

Speaker Appearances 2018

One of the highlights this year was to be awarded the JCP Outstanding Spec Lead Award together with Christian Kaltepoth for our work with JSR 371.

Getting the JCP Award for Outstanding Spec Lead 2018

Another acknowledgement by the community was to be re-elected for an associate seat in the JCP Executive Committee.

Besides speaking at conferences, a great deal of my time in 2018 was dedicated Jakarta EE at the Eclipse Foundation where I act as the PMC Lead of EE4J a well as being a member of the Steering-, Specification-, and Marketing Committees in the Jakarta EE Working Group.

All in all 2018 was an eventful year and I expect no less of 2019!

While Waiting for Jakarta EE

It is more than a year since Oracle announced the transfer of Java™ EE to Eclipse Foundation at JavaOne 2017. Since then, a lot has happened:

  • Java™ EE 8 API and implementation projects have been set up under EE4J.
  • The Eclipse GlassFish 5.1 release is approaching.
  • A brand new Jakarta EE specification process is right around the corner.
  • Community shows involvement regarding the technical direction of Jakarta EE.
  • The Jakarta EE NoSQL specification project proposal has been created.

This is all very good, excellent actually! When you think about the size of it all, it is actually quite an achievement. We are talking about 7.7 million lines of code! More than 60.000 files and a total of 38 new projects that have been set up at the Eclipse Foundation.

But, as everyone knows, developers are impatient and eager to try out everything new, so there are still a couple of questions that I always get when talking about Jakarta EE:

  • When can I start developing Jakarta EE applications?
  • How does Eclipse MicroProfile fit in this picture?

The answer to the first question is: “not yet”. Until the Jakarta EE specification process is finalized, the technologies are still Java™ EE. 

The answer to the second question differs a little depending on who you ask, but usually is something in the lines of “I am pretty sure that some of the MicroProfile specs will be integrated into Jakarta EE when they have proven to be useful”.

So, what should an eager developer do in the meantime? Switch to Spring Boot…ouch…or…JavaScript…squeal…?

NO, here is what you should do: Use the power of JavaEE 8 and combine it with Eclipse MicroProfile.

Many of the application server vendors have added MicroProfile features to their Java™ EE 8 compliant or certified application servers. Examples are Open Liberty, WildFly, Payara and Apache TomEE. See the respective vendor’s documentation for which versions they have included.

Java EE 8 with Eclipse MicroProfile 2.1

I have put together a simple application called Jakarta EE Duke to demonstrate how to do this. The application uses the @ConfigProperty annotation from MicroProfile Config to configure a message as well as the new @Email annotation from Bean Validation 2.0, which came with Java™ EE 8 to validate input.

While this example is extremely simple, it does indicate how you can combine the full power of Java™ EE 8 with the lightweight APIs of MicroProfile to implement cloud-native microservices using Java™ technology.

One last tip: Make sure to join the Jakarta EE Community Mailing list to always stay up-to-date on the latest development of Jakarta EE.

Eclipse GlassFish Release Plan

UPDATED!

Yesterday, the release plan for Eclipse GlassFish was announced on the EE4J mailing list. For convenience, I have repeated the plan here:

September 18
All code required for GF build contributed.

September 23
Eclipse GlassFish builds.

October 1
Java EE 8 CTS testing. We are able to run CTS tests on Eclipse GlassFish.

October 22 ⚡
CI/CD release pipelines completed.

October 22
Eclipse GlassFish 5.1-RC1 milestone release.

November 5 ⚡
Dependencies updated. All projects are released to OSSRH and have dependencies to Eclipse version of other components.

November 30 ⚡
Release Review completed.

December 14 ⚡
Eclipse GlassFish 5.1 release. All CTS tests are passed.

There is a lot of work to do, so every contribution is appreciated, especially regarding setting up the CI/CD pipelines for all the EE4J projects. Take a look at our status sheet and sign up where you think you can contribute.

Ozark becomes Eclipse Krazo

One of the requirements for Eclipse Projects is that the name is not associated with any trademarks or potential trademarks. When we created the project proposal for Ozark, this turned out to be the case here. The name Ozark is simply used too many places for it to be a valid Eclipse project name.

So, how did we come up with the new name? First of all, we asked for input on the Ozark developer mailing list. We also wrote a small program that generated all permutations of ‘ozark’ to see if something cool came out of that.

Then we started filtering, discussion and voting until we ended up with Krazo, which turns out to be Ozark spelled backward. We are really excited about the new name and hope you all will join us in spreading the word that the reference implementation of MVC 1.0 that was previously known as Ozark is now called Eclipse Krazo.

Setting sails for Jakarta EE!

The future of Cloud Native Java with Jakarta EE is here! The Jakarta EE website was launched today with lots of information, news and resources, including the new results of the 2018 Developer Survey.I even got my blog posts about the relationship between Jakarta EE, EE4J and Java EE listed in FAQ section. The website even features the new Jakarta EE logo.

I should be honest and say that it wasn’t my first choice when I voted, but when I see it in use with different colors and backgrounds, I must admit that it looks pretty good.

The initial strategic and participating members of the Jakarta EE working group are also listed on the website.

It is pretty awesome to see this list of companies participating and supporting Jakarta EE! And the list is likely to expand as more companies join. The future of Cloud Native Java is Jakarta EE, and the future looks bright. Let’s set the sails and sail towards the future (finally got the logo, I think…).

https://jakarta.ee

 

The Relationship Between Jakarta EE, EE4J and Java EE

The Jakarta EE name has been out for about a month, and even if Mike Milinkovich explained the names and concepts pretty well in his blog post And the Name Is…, there still is a bit confusion about how it all relates and I get questions around it whenever the topic comes up. I have tried to sum up some of it here. Hope it helps!

Java EE

Java EE, or Java™ Platform, Enterprise Edition, is the name of the current platform governed by the Java Community Process (JCP). The latest version is Java EE 8, which was released in September 2017.

Jakarta EE

Jakarta EE is the name of the platform governed by the Jakarta EE Working Group. The first version will be Jakarta EE 8 which will be based on the Java EE 8 technologies transferred from Oracle to the Eclipse Foundation.

EE4J

Eclipse Enterprise for Java (EE4J) is the top level project in the Eclipse Foundation for all the projects for creating the standards that will form the base for Jakarta EE. The EE4J Project Management Committee (PMC) is responsible for maintaining the overall vision for the top level project. It will set the standards and requirements for releases and help the projects communicate and cooperate.

Summing Up

Jakarta EE does not replace Java EE! It is the name for the platform evolving with Java EE 8 as a starting point. Java EE 8 will still exist, but there will not be any new versions of the platform.

Jakarta EE does not replace EE4J! It is the name of the platform based on the EE4J projects with Java EE 8 as a starting point.