I had learned the core Java language years before and I knew Java was "enterprise", so I figured that might be a good spot to start, so I bought a book on J2EE development with GlassFish, downloaded all the appropriate SDKs, and after multiple days of spending nearly every minute I could on it, I got something not quite as good as something I could have whipped together in ColdFusion (or Railo/OpenBlueDragon) at the time.

I thought that maybe I was just stupid, and I suppose the jury's still out on that, but shortly after that experience I found a Django tutorial series on YouTube and went through that, and felt like I was productive almost immediately. I was able to build "real" stuff in a matter of a few hours instead of days, and it didn't feel like it was more chaotic than the stuff I had done with J2EE. I then did a similar experiment with Rails, and had the same effect: me being an idiot is not solely to blame for me not really grokking J2EE. Eventually I learned Node.js and did that for a few years, until I was able to (thankfully) transition out of "web development" entirely.

Personally, while I'm sure the Glassfish server, and maybe J2EE has its merits, I don't think they're worth the headaches I went through to try learning it. Java has plenty of cool frameworks now (e.g. Play, vert.x), but I've never even tried using those with Glassfish.

Glassfish, Wildfly (what was JBoss), Apache TomEE, Payara (Glassfish fork), Open Liberty are all active and maintained OSS EE servers.

Then there are the commercial only servers Weblogic and WebSphere and likely others.

The Jakarta EE world is vibrant and robust, with a lot of the activity at the Mircoprofile and container level, since most of the core capabilities are quite mature. It's no longer some monster EE server running everything, necessarily. It supports all sorts of scenarios. After the name fork from Java EE to Jakarta EE, and the transfers of everything to Eclipse, the paperwork is finally slowing down and momentum building back up.

Having written EE code for over 20 years, across servers, platforms, porting code, I have long appreciated what JEE brought to the table.

Spring is a powerhouse, make no mistake. They have done a lot of innovation, and the EE standards are absolutely a reflection on things they brought to the table first along with insights from other parties.

But they're just one implementation. The core JEE services have a wide array of implementations all with their own quirks and benefits.

The folks working within the JEE standard track help lift all boats as, in time, all of the implementations catch up to the latest specifications. So it's a bustling and competitive space, without necessarily being completely wild west. The gives a lot of power to folks developing on top of it, with a platform offering reasonable stability while still offering diversity of implementations.

Didn't that exact thinking got us into trouble over and over?

Why would you ever use any other browser instead of browser X? What follows is the browser X getting 99% of the market, and the vendor of X becoming lazy and ruining X completely.

> and you can AOT compile it with graal!

You can do that already (and have been able to do so for some time) with Quarkus (a partial EE implementation, related to JBoss/WildFly) and things like Piranha Cloud.

Helidon (another partial EE implementation) has been working on virtual thread support with a custom HTTP engine build in cooperation with the JDK team.

Constant update is needed because constant security issues keep popping up and crappy APIs need constant refactoring. See RestTemplate vs WebClient vs RestClient. Writing a decent HTTP client seems impossible for them and keep getting replaced with new API and its not even like HTTP is changing every few months.

I do know some enterprises that still run JBoss so it’s not entirely like no one would use this. However, they are all in the process of refactoring for the cloud off of JBoss JEE.

This question gets very confusing though, because I believe that a lot of developers love to purposefully obfuscate it. The terms "Java EE" and now "Jakarta EE" can be looked at in two different ways:

1. A collection of various API standards, that may be implemented to some degree and/or extended by various libraries.

2. Developing against an all-inclusive application server such as WebLogic, WebSphere, Glassfish, etc... that comes with implementations of all those API's. Where your application is configured to rely on those implementations that come with the application server, rather than bundling up its own dependencies itself.

The thing is, when people ask "Who uses Jakarta EE?", they are almost always thinking about #2 there. Who in 2023 is still developing to WebLogic, WebSphere, Glassfish etc as a target environment, and relying on the library implementations that come with that server?

I THINK the answer to that is "pretty few people".

However, people who have pinned their careers to those stacks, and/or sticklers who love to be contrarian, often bait-and-switch with the #1 definition above. They will point out that Spring uses some implementations of some of those Jakarta EE specs, and therefore "Spring IS Jakarta EE" or at least "Spring depends on Jakarta EE".

That's not really good faith, though. One of Spring's strengths is that it can INTEGRATE with virtually everything. But that doesn't mean that much of anything is a requirement for using Spring. For example:

* By default, a Spring Boot application with the "web" starter pack embeds Tomcat for HTTP services. So people can say that's "using the Servlet spec". Except that Spring doesn't necessarily have to use Servlets. You can override that Tombcat dependency with Netty, which is not Servlet-based and not part of Jakarta EE at all, and probably not even have to change any of your code. The old-school Servlet spec is neither here nor there to writing a modern Spring controller class.

* By default, if you use Spring Data with the "JPA" starter, then you are using Hibernate, which is an implementation of the JPA spec. However, you certainly don't HAVE to. There are flavors of Spring Data that provide similar functionality, backed by plain JDBC. Not to mention spins for MongoDB, Redis, and other databases that are completely outside the scope of Jakarta EE.

So on and so forth. A Spring application MIGHT be using a Jakarta EE API somewhere, but by no means does it HAVE to, and they often don't. So in my opinion, it's extremely disingenuous to take that "#1" definition, of Jakarta EE being a loose basket of API's, and use that to give people the impression that the "#2" definition of Jakarta EE as an old school fully-integrated app server is more widely used today than it actually is.

In 2001 the product wasn't called GlassFish yet, and even the Sun ONE Application Server name wasn't there yet.

The name GlassFish wasn't introduced until 2005 and had its first release the year after that.