Unfortunately the name Glassfish has been pretty tainted by now. If you say your platform is based on Glassfish they'll automatically assume you're an old donkey not up to date on latest Java technologies like Spring Boot.
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.
I shipped GlassFish 3.1 as an on-prem appserver for our observability product for a few years, and have nothing but good things to say about it. It's great to see the project recovering from the abandonment.
Why would you compare Eclipse GlassFish instead to Payara or Wildfly/JBoss?
Anyway, that bickering between JEE application server vendors is what caused Spring to win. It doesn't matter it has update churn that is almost as bad as in JS ecosystem, just the fact you don't have to think about AS helped adoption. Well that and significantly easier testing. And Spring Data with generating queries from method names.
And you can't recruit people with JEE knowledge anyway, they all know only Spring.
Back when JEE was still proto-matter, we had the early versions of JBoss, but it was very raw, and hard to use.
Sun released the Sun Java Application Server 8 (no idea where 1-7 were). It was closed source, but free license for production. It was a much nicer out of the box experience with the platform.
They then rewrote that into Glassfish 1. Free to use, open source, great web UI, great CLI. It was both the JEE reference platform and designed for production.
GF evolved over the years, keeping up with the JEE standards. They refactored it on top of OSGI to improve start up and modularity. If you were so motivated, you could do hybrid OSGI and JEE apps on top of GF.
I used GF in production for years. Never had any big issues with it. The JEE standards worked for us when we ported a large, legacy Weblogic app built in early 2000s to GF, perhaps, 10 years later. All of that legacy sharp pointy XML came right over to the new server, it still supported the original assemblies.
GF suffered from the JEE exodus out of Oracle. Oracle has been an absolutely amazing steward of Java, and I'm not even suggesting that they shouldn't have parted out JEE like they did. But that was a rough patch, and GF withered. Payara pretty much picked up the standard and ran with it from the GF code base, and they've been very good for it.
Its nice that someone is working to keep GF production. Originally, GF had a pretty nice clustering facility that has since been removed. I think it's more an attitude to focus on a production oriented system rather than a reference system that's important, more so than, perhaps, higher end features. Just focus on stability and performance.
(glassfish is a Java application container, provides DB, http server etc for apps using the standardized interfaces, now more in the micro-profile corner away from the oldern days JavaEE tar pit)
I use jersey+glassfish to build very small micro-profile applications.
It's stable, small and works.
Not a fan of the HK2 dpendency injector though. Maybe that's my general dislike of how convoluted the spec and implementation (of EE di) is.
I hate how sprawling the (other) implementations are, no it is not ok to pull in 90mb dependencies to support things I don't need. These app servers tend to grow into huge uncontrollable messes. Nobody uses standalone containers anymore and forcing people to pull in all or nothing for the embedded version is just asinine engineering.
When I see 'JEE Java application server', I always wonder:
* How many applications actually target multiple JEE servers
* Whether stuff like Glassfish and JBoss have to spend as much time selling the paradigm as the product
Personally speaking neither company I've worked out used JEE. We used Tomcat at the last place and the Play Framework at my current place.
I'm not sure that the benefits of long-running Java application servers that you can load and unload JAR-applications from exist (especially when unloading JARs has always been a mess).
47 comments
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.
>”latest Java technologies like Spring Boot.”
Which are already old enough to drive… latest my ass.
Back when JEE was still proto-matter, we had the early versions of JBoss, but it was very raw, and hard to use.
Sun released the Sun Java Application Server 8 (no idea where 1-7 were). It was closed source, but free license for production. It was a much nicer out of the box experience with the platform.
They then rewrote that into Glassfish 1. Free to use, open source, great web UI, great CLI. It was both the JEE reference platform and designed for production.
GF evolved over the years, keeping up with the JEE standards. They refactored it on top of OSGI to improve start up and modularity. If you were so motivated, you could do hybrid OSGI and JEE apps on top of GF.
I used GF in production for years. Never had any big issues with it. The JEE standards worked for us when we ported a large, legacy Weblogic app built in early 2000s to GF, perhaps, 10 years later. All of that legacy sharp pointy XML came right over to the new server, it still supported the original assemblies.
GF suffered from the JEE exodus out of Oracle. Oracle has been an absolutely amazing steward of Java, and I'm not even suggesting that they shouldn't have parted out JEE like they did. But that was a rough patch, and GF withered. Payara pretty much picked up the standard and ran with it from the GF code base, and they've been very good for it.
Its nice that someone is working to keep GF production. Originally, GF had a pretty nice clustering facility that has since been removed. I think it's more an attitude to focus on a production oriented system rather than a reference system that's important, more so than, perhaps, higher end features. Just focus on stability and performance.
I use jersey+glassfish to build very small micro-profile applications. It's stable, small and works.
Not a fan of the HK2 dpendency injector though. Maybe that's my general dislike of how convoluted the spec and implementation (of EE di) is.
I hate how sprawling the (other) implementations are, no it is not ok to pull in 90mb dependencies to support things I don't need. These app servers tend to grow into huge uncontrollable messes. Nobody uses standalone containers anymore and forcing people to pull in all or nothing for the embedded version is just asinine engineering.
* How many applications actually target multiple JEE servers
* Whether stuff like Glassfish and JBoss have to spend as much time selling the paradigm as the product
Personally speaking neither company I've worked out used JEE. We used Tomcat at the last place and the Play Framework at my current place.
I'm not sure that the benefits of long-running Java application servers that you can load and unload JAR-applications from exist (especially when unloading JARs has always been a mess).