My Thoughts on Jakarta EE

The Announcement

On February 26, 2018, I saw a post on Twitter saying EE4J tallied the results of the naming survey and Jakarta EE is the new brand for the open source enterprise software standard (Milinkovich, 2018). From what I’ve seen on Twitter and read on other blogs, the Java enterprise community has been very supportive of the re-branding. I am supportive as well (I voted for Jakarta EE) and will continue to evangelize Jakarta EE. Though this is a monumental step, the challenges for EE4J and the Jakarta EE brand are far from over. I’d like to share what I think are some of those challenges. You can skip to tl;dr to save time. They are:

1. Getting the Re-branding to Stick
2. Release Cadence
3. Continued Emphasis on the EE Server

Getting the Re-branding to Stick

The announcement hadn’t even been a day old when Twitter posts started from recruiters looking for Jakarta EE experience (Ament, 2018). Java Enterprise software has been around for nearly 20 years, and over that time it has gone through previous cycles of renaming and re-branding. Here they are:

J2EE (1999) -> Java EE (2006) -> Jakarta EE (2018)

Re-branding is hard, and it can be argued that neither Sun nor Oracle did a good job promoting the brands. You can search Twitter for posts joking about how it has been over 10 years since the re-brand to Java EE but recruiters still advertise and look for “J2EE”. I am guilty of this as well. My LinkedIn profile has “J2EE” all over it so I can be found.

So how will EE4J fair promoting the Jakarta EE brand? I think success can be measured by management knowing about it. It’s sometimes dangerous when managers know things. But, if managers start asking, “are we are using Jakarta EE in new projects”, that’s success in branding.

NOTE It’s OK if managers don’t know what Jarkarta EE is, as long as they know it’s the “thing to do” :)

Release Cadence

Java SE is experiencing this challenge right now. The Java community griped about how long it took for Java to evolve and release new versions. Now that Oracle announced Java SE is on a 6 month release cycle (Evens, 2017) with limited long term support options (Azul, 2018), organizations don’t seem to know what to do (be careful what you wish for). Software is moving faster than infrastructure can keep up.

Release cadence can be a problem with Jakarta EE as well. The Java enterprise community may get its wish with rapid releases of Jakarta EE. But if this happens, I don’t think the releases will get the fan fair the community expects. Infrastructure won’t be able to keep up. Organizations will keep to their multi-year upgrade plans meaning long periods of time between server upgrades. Jakarta EE developers will be stuck using old standards like Java EE developers are stuck now.

A rapid release cadence for Jakarta EE may even cause more harm than good. As it is now, if an organization is upgrading servers every few years, the perceived risk of the upgrade is somewhat reduced because the standard may change by only 1 number: Java EE 6 to 7. On paper, that doesn’t look too risky. But if there have been multiple release over the years and the change is from Jakarta EE 9 to 14, the perceived risk is now YIKES!

I think Jakarta EE can support a rapid release cadence. However, to do this it has to face what I consider to be its most daunting challenge: the server.

Continued Emphasis on the EE Server

The final and most glaring challenge EE4J faces is continuing to remain server-technology focused. Will Jakarta EE continue to focus on the standards to create an “EE Server”? I hope not!

20 years ago, the expectation was to install a “heavy” server (WebLogic, WebSphere) and be able to ride that installation with very few changes for 3–5 years and you’re all good. Even security patches over those years were very limited; it was a different era! That’s the way infrastructure worked then, and if we are honest with ourselves, it’s the way infrastructure works now. Infrastructure is a huge impediment to software development. Developers want to use the latest-and-greatest, but infrastructure does not want to “take the risk”. Upgrading server software is always painful: lots of testing, lots of things breaking. So infrastructure avoids upgrades as much as it can.

The development community has gotten around this infrastructure problem by moving functionality out of the server and into the application, hence the Spring framework. Spring is successful precisely because of this infrastructure problem. Infrastructure typically does not care what’s inside the applications running on the server - the applications can change and upgrade as much as they want - just so long as the server itself doesn’t have to change. Is your production WebSphere installation 10 years old? “No problem,” developer’s say, “We aren’t really using anything the server provides anyway.”

Jakarta EE needs to evolve into a standard for an enterprise framework vs. an enterprise server. Spring, Hibernate, and other open source project can continue to push innovation forward. Organizations that want to take the risk and use those bleeding-edge technologies can do so. Once proven, their innovations can be incorporated into the Jakarta EE standard framework for the rest of us. Jakarta EE developers can use the new features added to the framework as quickly as their next product release by a simple POM <version> update…no need to install a new server. As an added bonus, if Jakarta EE sticks to TCK requirements and backward compatibility, Jakarta EE developers will have the confidence things won’t break when they change that often feared <version> number.

If Jakarta EE evolves into a standard for an enterprise framework (I hope so), Jakarta EE applications still need to run in something. Perhaps keeping to the current trend of using the Servlet container (Tomcat, Jetty) would be sufficient. But whatever form it takes, the expectation should be that the “server” would be able to sit for 10 years with minimal updates and not get in the way of the applications running in them. When the EE4J charter was under review, I believe there was some discussion on using the word “runtime” instead of “server”. This is appropriate. Have a Jakarta EE runtime (JEER) that can run for years without requiring major upgrades.

tl;dr

I fully support Jakarta EE as a brand and will continue to evangelize the technology as an open standard for enterprise development.

Successfully branding Jakarta EE will be a challenge. Branding will be successful if managers start asking, “Are we using Jakarta EE”? Jakarta EE should be a buzz word and the “thing to use” even though people may have no idea what it is. Sound familiar?

Release cadence may backfire on Jakarta EE because upgrading server installations will continue to move a lot slower.

Jakarta EE needs to evolve into a enterprise standard framework, deployable as part of an application vs. an enterprise standard server that has to be installed or upgraded on a box. The former results in speed, agility, and innovation. The latter results in stagnation.

Thanks for reading.

References

Milinkovich, M., (2018, February 26). And the Name Is…[Blog Post]. Retrieved from https://mmilinkov.wordpress.com/2018/02/26/and-the-name-is/.

Ament, J. D., (2018, February 26). This just in [Tweet]. Retrieved from https://twitter.com/JohnAment/status/968324168264704000.

Evans, B., (2017, September 6). Java to Move to 6-Monthly Release Cadence [Blog Post]. Retrieved from https://www.infoq.com/news/2017/09/Java6Month.

Azul Systems, (2018, January 17). Azul Systems Announces Enhanced Java SE Support Plans [Blog Post]. Retrieved from https://globenewswire.com/news-release/2018/01/17/1295592/0/en/Azul-Systems-Announces-Enhanced-Java-SE-Support-Plans.html.