What's New in Jakarta EE 10?

According to Wikipedia, it happened in 2018 and was (of course) due to Oracle's trademark on Java™: https://en.wikipedia.org/wiki/Jakarta_EE#cite_note-7

relevant: https://xkcd.com/1053/

Jakarta EE is Java EE. When Oracle bought Java they cut Java EE loose because Spring and Spring Boot were eating the world and Oracle didn't want to be in the business of maintaining the losing Java enterprise framework. But they couldn't call it Java EE anymore because Oracle holds the Java trademark.

Relevant: https://jakarta.ee/about/faq/#collapse-1

Are you the co-creator of Jakarta Tomcat?

I'm the opposite, can't wait for app containers to go away. Probably have their place but it's giving up control to some stateful black box. I always embed a jetty or something and do my own hikaricp.

Well, I know what all that stuff means, and I’m so very, very happy not to be part of that ecosystem any more.

I feel this way too. Clojure looks awesome. Kotlin looks nice. People tell me that even Java is pretty good now. There are a lot of JVM libraries and people say that the JVM itself is an engineering marvel.

But... the ecosystem is incredibly intimidating and there is no obvious starting point for a beginner. I know that with Clojure you can probably just stick to "Clojure stuff" like deps.edn, but that's also not really why people choose Clojure in the first place, nor does it seem like a sensible path to competency.

And I say this as a Python professional and a Common Lisp and Scheme hobbyist. My personal tolerance for chaotic and/or offbeat tooling ecosystems is high.

So.. which ecosystem do you like to look at and feel pleased? virtually all of them have some sort of notion of packages and versioning

I don’t think it is harder than any other ecosystem of similar size, it’s just unknown to you and feel different.

Jakarta EE is the old Java EE’s continuation, which is a huge standard for solving many kinds of complex business requirements (dependency injection mostly, with aspect-oriented programming). In a way it is a Spring alternative, but the truth is that Spring also uses several annotation of the standard so it more like building on top a subset of it. While it is a difficult topic, it is an ecosystem in its own right, so I don’t think it is meaningful to discuss it with Java itself — one can make a whole career as a java dev without touching it.

Package management is basically either maven or gradle, but both use the same registry for the most part, so on the surface level they both are quite easy to use.

I would guess you mean java’s versioning (eg. 8, 17, etc) - this couldn’t be easier, it’s just an integer that increases every 6 months. That is, for OpenJDK. This is the JVM-implementation, being both the reference and the most often used one. It has several forks that you might have heard of, but they share more than they differ. Some of these forks/vendors provide LTS-releases and this usually targets 8, 11, 17, 11+6k versions. That’s pretty much it.

In the meanwhile you literally have to use a tool to generate a base repo to write anything more complex than hello world in the JS ecosystem :D

What ecosystem is simpler?

After writing this comment and reading some others, I was reminded of CDI - the dependency injection blackbox. It was advertised as the next best thing to allowing developers to focus only on their business logic and let the CDI runtime inject the dependencies. That turned out to be giant mess. Couldn't understand what a piece of code was doing statically and you had to run the code, attach a debugger to find out what dependency got injected and what its implementation looks like. And of course, things behaved differently because some other dependency implementation got picked up and injected instead of the one that you had debugged in dev environment.

Simple code turned into a complete dependency injection spagetti just beacuse CDI was a specification and advertised as the next best thing to come from the Java EE ecosystem.

I am really glad we moved away from that area.

I happened to reread part of an original EJB book, and with hindsight I am now wondering if EJB = microservice was the intended use. The app server would, on multiple machines, start and stop EJB instances like kubernetes does with node instances. The whole thing tries to hide there is a network in there, automagically connecting everywhere.

Which would make the whole bloat thing moot and the whole EJB stack comically misused.

But look at it as an EJB providing an interface to the outside world. Forget about making almost every class an EJB. Then the 2 styles start to look quite similar, especially if 'the network is the computer'.

There were of course still plenty of bad design decisions. Every vendor has its own RMI variant, requiring drivers instead of a standardized http+json. 4 files for the interfacevis iver the top. The EJB database interface was bad.

I disagree. A "what's new in <X>" post shouldn't describe what <X> is. Most of the people interested in updates on <X> will already know what it is, so adding that information to every article would be redundant.

They helpfully link to the jakarta.ee site which has an about page.

Jakarta EE is all of the Java EE spec that are now open sourced. Right now in Java-land, the big development ecosystems are Quarkus, Spring Framework, and Jakarata EE. Jakarta EE's big advantage is CDI, which is a very nice dependency injection container and allows applications to be broken down and composed into easily testable modules. Quarkus partially implements CDI and has its own set of APIs. Spring has their own DI container that is showing it's age, but is still quite popular.

Java EE is basically a collection of API that are shared accross different Java web servers. It's a spec so basically you develop your java app on say glassfish server and you can deploy it on websphere, the servers holds all the libraries you need to run your app, so you can just deploy some small java zip file.

Because of trademark issues with Oracle around the name Java, the open source community had to rename all its API jakarta instead of java which is completely stupid and is a demonstration that Oracle is just here to milk the name Java.

Oracle open sourced and released the bulk of the Java Enterprise Edition specifications and source code.

But what they did not do, is release the Java trademark. So, the whole kit had to be called something else (in this case they chose Jakarta, which has history in the Java community and lets the colloquial "JEE" still work).

Part of this process what they had to rename ALL of the Java EE packages from the original "javax" root name to something else, again, in this case, "jakarta".

This has been a several year process that's held up a lot of advancement in the platform as it transitioned out of Oracle and over the Eclipse foundation.

At this point with moving to Java 11 and supporting Java 17 (no small feat), and having all of the packages renamed, repackaged, re-released, Jakarata EE is probably "finally free" from where it was back in "Java EE 8".

Jakarta EE has several profiles, each focusing on different subsets of the overall EE platform. Web Profile is one of those subsets that focuses on the Web aspects of Jakarta EE. For example, Tomcat is more of a Web Profile stack (I don't know it Tomcat officially supports it or not) compared to the full boat EE containers like Glassfish, Websphere, etc.

Jakarta Concurrency (which is essentially portable access to container managed thread pools and other similar resources) was originally part of the full EE specification. Now they've moved it to the Web Profile so it can be used in those containers that do not support the entirety of Jakarta EE.