henk53

> We are wired to be needed, wanted, useful, accountable, social.

When AI eventually takes nearly ALL jobs, that will be a quite difficult thing.

> single, self contained deployable

EE doesn't exclude that model at all.

For the most part, maybe like 99%, the Jakarta APIs are agnostic of what the deployment model is. They are APIs to validate input, service HTTP requests, store data in databases, look up roles, connect to identity providers, etc etc.

> I thought that was Tomcat or was Tomcat just the servlet reference implementation

Tomcat itself has never been an official reference implementation of anything.

Tomcat implements various Jakarta EE APIs, most centrallly Servlet indeed, but also JSP (Jakarta Pages) and JSTL (Jakarta Tags), WebSockets and Jakarta Authentication.

The initial Tomcat was donated to Apache, then used back in GlassFish. GlassFish WAS the reference implementation of Servlet (among others), so indirectly Tomcat kinda was the reference implementation indeed. But just a fork of its code via GlassFish.

> Spring won. Why would anyone want to learn the standard aside from it being a standard that few people use?

People don't really talk about Jakarta EE as "the standard". Haven't been doing that for quite some time.

You learn it so you don't hand Spring the ultimate monopoly. I thought we all didn't like monopolies? Why give Broadcom one?

IBM already owns Red Hat, but for a few years it operated as a largely individual company still.

> Spring is just a framework, not an application server with isolated classloaders that the JaveEE application servers were based on.

But Spring Boot with its embedded HTTP server and internal infrastructure is certainly more than just a framework. It has its own class loade (launchedurlclassloader). See https://dzone.com/articles/spring-boot-classloader-and-class...

Piranha Cloud on the other hand runs Jakarta EE code without any class loader of its own. See https://blogs.oracle.com/javamagazine/post/you-dont-always-n...

> JavaEE somehow associates with managing applications through the Application Server’s admin panel,

That is a wrong association really.

Even in the really old versions of GlassFish and JBoss such an admin panel was just an extra (I hate them too, btw).

You could always, Tomcat style, just copy your .war to a deployment folder. If you wanted, you could also zip up GlassFish with the war already in that folder and deploy that.

> registering EJBs with deployment descriptors

That was required for the last time in J2EE 1.4, from 2003 or so. Already in Java EE 5 from 2005 that wasn't necessary anymore. Also don't forget that spring beans needed to be registered in very similar deployment descriptors (huge xml files) just as well.

Java EE 6 was pretty decent really. It came with JAXRS, CDI, Bean Validation and JSF 2.

If you used J2EE in 2012, did you happen to get that idea from a very old book?

J2EE ended in 2005. So if you used it in 2012 it may explain something.

Isn't this very article about directly running GlassFish from Java SE?

You could also say btw that GlassFish doesn't need any WebSphere or JBoss. Or you could say that WebSphere doesn't need a JBoss or GlassFish.

Also, WebSphere is legacy within IBM. Their new and much much better server for some time is called Open Liberty. It uses some components from WebSphere, but in a highly modularised way, and the overal runtime is totally different.

> LOL - I wondered if I had just travelled back to 2001 when I saw this.

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.

Also, for a very long time, Spring Security had native integration connectors for JBoss and maybe some other EE servers. They only removed these much later.

> Last worked in EJBs in 2002. There’s still a bad taste in my mouth.

Although EJBs got improved so much in 2006 it was nearly a different technology, EJBs by themselves have been largely deemphasized in Jakarta EE. The main bean model is CDI and has been for some time.

There's a 3. really, which are products using Jakarta EE APIs extensively (maybe even all of them), but aren't application servers.

Oracle themselves (they create such runtime, called Helidon) have a blog post out about just that:

https://blogs.oracle.com/javamagazine/post/you-dont-always-n...

> Why would you ever run Jakarta EE nowadays instead of the defacto standard Spring Boot

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.