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.
> 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.
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.
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.
> 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.
It's Jakarta Faces now ;) And it's still relative active with a major new version (Jakarta Faces 4) in Jakarta EE 10. Of course the entire concept of server side rendering is not as much used as it once was, but that said it's still used.
Not really, Jakarta came from Java EE, which came from J2EE, which was released early 2000. Spring is from 2003 and started essentially as a framework for J2EE.
> and influenced it a lot.
It goes both ways.
Spring for instance started calling code "configuration" and wanted us to put it in huge amounts of XML. Java EE started with using annotations for bean definition and injection. Spring was initially against this idea, arguing configuration should be external and not embedded in the code. Citing that you would otherwise needed to recompile your code in order to change configuration.
Many years later Spring projects barely use those huge XML files anymore and its all autowire.
I'd have a small preference for Eclipse, mainly because some specs are already there (like EclipseLink).
Apache already has their own implementation of much of Java EE (via the Geronimo project, TomEE and Tomcat, among others).
In my opinion it would be slightly confusing to have say 2 JSF implementations at Apache (Myfaces and Mojarra). Not really terrible, but my gut feeling says Eclipse would be a better home.
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.