Sorry, I'm using J2EE when I really meant JavaEE. A lot of message boards and whatnot at the time still called it "J2EE" so that's what I remembered it as. I think the version was 6 at the time?
I'm sure it's fine once you learn it all, and I'd probably be able to pick it up quicker now since I have a decade more of experience, but my difficulties with it was not for lack of trying on my end. I found a lot of the terminology difficult to work with, and it felt like doing anything required me to touch a million files across a thousand folders.
As I said, I don't really do web stuff anymore; when I need HTTP nowadays I generally want something a bit quicker and lower level than a full-on web framework.
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.
Maybe you are right. But to me, JavaEE somehow associates with managing applications through the Application Server’s admin panel, registering EJBs with deployment descriptors, etc.
> 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.
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.
By my earlier statement I meant that the old JavaEE application servers with standalone EJBs deployed as ejb-jars and JMS were good infrastructure while now JavaEE tries to become the next SpringBoot.
In .Net I would prefer to have application servers instead of an operating system performing the same function. Blazor is nicer to use than JSF and Entity Framework than JPA.
> 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.
