ondromih

Jakarta EE gives a lot of options. It evolved.

Running an app server for a long time and redeploy apps to it is just one of them. To be honest, rarely used nowadays.

Many Jakarta EE products support:

* deploying apps on startup, just like Tomcat * bundling the server into a self-contained app, just like what SpringBoot does with Tomcat * running an app from command line, which Tomcat doesn't support - you have to drop the app into a predefined directory, SpringBoot doesn't support it either - the only option is to bundle the app and the server together during build

Some app servers are very lean, start in seconds, just like SpringBoot. Yeah, Tomcat starts faster, but only with a small app. If you add more libraries, you'd likely get to the same startup speed as SpringBoot or Embedded GlassFish.

I think the perception that JEE means big app servers where you deploy multiple apps and rarely restart the server, is very outdated. Nobody really uses Jakarta EE like that anymore. In fact, Jakarta EE is just APIs, the implementation can vary. Quarkus and Embedded GlassFish are perfect examples. Quarkus, although not fully Jakarta EE, can even build apps to native binaries. And Embedded GlassFish can run the same apps designed to run on app servers, on command line, without any installation of an app server.

People like simple life with as few choices they have to make as possible, right? It's now very simple to start a Java project, when the obvious choice is Spring and everybody uses it.

But is it what everybody really wants? To have a single choice? GlassFish provides a choice for those that don't want to become stuck with the "only" option that everybody uses. Java itself provides a lot of options - Oracle JDK, Azul JDK, Corretto JDK and many others. And that's a good thing. Options in frameworks and application servers are a good thing too. The best option wins. Except, there's rarely the best option for every case. And it's good to have all the other options too, in case the most popular option isn't a good one for you.

That's what the article is trying to deflect, isn't it?

Many people rely on vibes from the past instead of updating their knowledge with the current info. It's true that some companies in the past attempted to taint GlassFish to promote their alternative products. And there was nobody to defend GlassFish and keep it up to date.

This is different now, with GlassFish at the Eclipse Foundation, the OmniFish company behind it and providing enterprise guarantees, and GlassFish itself modernizing with fast startup, runnable JAR, support for latest Java and Jakarta EE, Jakarta Data and NoSQL databases.

In a way, yes, GlassFish is a Java framework. Although also much more.

It allows running and manage applications on a server, which provides resources to the applications. And it also allows building standalone Java applications, with the server embedded in it, in a way that you would expect from a framework.

On top of that, it provides standard Jakarta EE APIs, so your applications don't need GlassFish, you can run them on other servers too. Or you can easily migrte from other servers and frameworks to GlassFish if you like it more. And you can learn Jakarta EE APIs even before you will use GlassFish, or hire somebody who already knows it even though they never used GlassFish.

Thank you for your feedback. I'm the author of the article and will review how I can improve this.

However, at a brief glance back at the article, The second sentence in the first paragraph says it's an "application server". Further below the illustration image, there's a text in bold that says "Eclipse GlassFish is now a production-ready, enterprise-grade platform".

So I'm really curious, whether the article didn't make it clear, or there was a lack of interest on your side.