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

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

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!

JCP Elections 2018

Time flies like a banana…

It is almost two years since I was elected to the Java Community Process Executive Committee and the end of my term as a holder of one of the two associate seats are approaching. That means that the elections for representatives in the EC is going on, and you have a choice to make!

If you are an associate member of the JCP and haven’t already decided who to vote for in the ongoing election, please read my position statement for a motivation why you should vote for me.

A vote for me is a vote for the Community
 – Ivar Grimstad

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.