6 ms·

Eclipse GlassFish: This Isn't Your Father's GlassFish

47 points by henk53 6mo ago

fyrn_ 6mo ago
Probably would be a good idea to include at least a single sentence somewhere near the top explaining what the heck a glass fish is.
- trashcluster 6mo ago
  A java framework, like Springboot
  - angelaguilera 6mo ago
    Nope. From the glassfish.org web page: "Eclipse GlassFish is a lightweight yet powerful open-source application server that fully implements the Jakarta EE platform."
  - gertrunde 6mo ago
    er... surely it's a Java application server? (i.e. in the same space as Jboss/Wildfly, WebSphere, etc) Historically, it was also the reference implementation application server for J2EE.
    - chasd00 6mo ago
      I thought that was Tomcat or was Tomcat just the servlet reference implementation, i can't remember. App servers like Glassfish were what operations people used before the concept of "devops". Developers wrote the code and admins/ops deployed the code on app servers like Glassfish. Devops was supposed to put developers in charge of the whole stack but every enterprise i've seen have a dedicated devops team that manages AWS/Azure/GCP and separate developer teams who write the code. So it's pretty much the same it's always been ironically.
      - henk53 6mo ago
        > 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.
  - ondromih 6mo ago
    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.
- stavros 6mo ago
  Exactly, I had to read way too far before giving up because I have no idea what Glassfish is.
- cess11 6mo ago
  In the Java world it is rather common to use something called application servers. These are meta-applications that provide your applications an environment with things like database abstractions and the like, as well as admin interfaces. It solves some of the same problems you might reach for Kubernetes or OpenShift for, your application gets access to external resources in structured ways and you get to look at dashboards. GlassFish is an example of such an application server. WildFly is more common, and is the artist formerly known as JBoss. If you have some knowledge in the enterprise Java ecosystem you can quickly and easily (or maybe not, it depends) deploy your creations into these.
- pvaldes 6mo ago
  > what the heck a glass fish is. In Biodiversity, a glass fish includes a few group of Asian fishes that show crystal transparent bodies to hide from predators. Specially when young. They are vertebrates that evolved transparent muscles. Two gens are kept in aquariums: Parambassis ranga and several ghost catfish from gen Kriptopterus. We can assume that the programmer likes aquariums. The word Yakarta is not random, as is related with the catfishes distribution.
  - cess11 6mo ago
    Jakarta was chosen by the Eclipse Foundation because it is the largest city on the island of Java, and Oracle is virulently litigious around the Java trademark. https://www.theregister.com/2018/03/04/java_ee_is_now_jakarta_ee/ https://www.theregister.com/2018/03/04/java_ee_is_now_jakart...
- znort_ 6mo ago
  probably this article isn't for you if "glassfish" isn't a familiar term. if curious (or fomo) it would have taken you about 15 secs to find out what glassfish is, which is still probably 15 less than what you wasted on this mini rant. from there it's up to you to go down the rabbit hole.
- ondromih 6mo ago
  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.
- riffic 6mo ago
  obviously you're supposed to know what everything is ahead of time on orange site.
  - deleted 6mo ago
    [deleted]
ysleepy 6mo ago
(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.
zvqcMMV6Zcr 6mo ago
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.
- bzzzt 6mo ago
  Spring and JEE (or Quarkus) are very similar, from the viewpoint of an application developer both have the same JAX-RS REST and Hibernate/JPA API's. IMO the kind of person who only knows Spring and doesn't understand modern JEE is exactly the kind of person you don't want to recruit.
  - gadflyinyoureye 6mo ago
    Spring won. Why would anyone want to learn the standard aside from it being a standard that few people use? Spring itself is a wildly adopted standard. It is a semi open standard in that anyone can use it freely, but in that it's not supposed to be implemented by others. The same is true for Micronaught or Quarkus. Learn the frameworks. But they are not a new open standard.
    - pjmlp 6mo ago
      Except people keep forgetting they implement the standards on their very foundation.
    - henk53 6mo ago
      > 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?
sgt 6mo ago
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.
- Cthulhu_ 6mo ago
  I love the irony / (perceived) sarcasm in your comment, :p.
- ondromih 6mo ago
  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.
  - sgt 6mo ago
    Fair enough. If OmniFish can properly support it and help it continuously develop it will have potential for adoption by even those using Spring.
- reactordev 6mo ago
  >”latest Java technologies like Spring Boot.” Which are already old enough to drive… latest my ass.
  - sgt 6mo ago
    I hear you, but there's genuine excitement still about Spring Boot and related technologies. See [1] Spring Cloud. [1]https://spring.io/projects/spring-cloud https://spring.io/projects/spring-cloud
boomskats 6mo ago
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.
philipwhiuk 6mo ago
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).
- ondromih 6mo ago
  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.
  - unscaled 6mo ago
    And this makes the entire application server and Servlet model the wrong abstraction. Microprofile simplifies things, but in the end I feel Java EE is just pushing the wrong abstractions here. Cloud native microservices are meant to be small, and receive their "cloud native dependency injection" through standard Unix interfaces like environment variables standard input and output, command line arguments and sometimes files. Cloud native apps are close in spirit to twelve-factor applications (which is a stricter rendition of that). Jakarta EE, even with its latest updates, comes from a different world. Standardized library API with interchangeable implementations that are injected by the application server. But wait! We flip the script by embedding the application server inside a fat JAR and shipping everything in a single docker/OCI container. A lot of the stuff that used to happen in the application server (load balancing, shared connection pooling, configuration, service discovery, service bus) happens now at the cloud infrastructure level. You can still use a MicroProfile-based framework, and Quarkus (which is based on MicroProfile) is very popular nowadays, but once you went along with a certain framework, you're not very likely to replace it. Standardization was the selling point of Java EE in the past, but in the microservice world when you're only betting a smallish microservice on Framework X, people are not so concerned about putting all their eggs in one basket anymore.
whartung 6mo ago
This is good to hear. 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.

47 points by henk53 6mo ago

fyrn_ 6mo ago

Probably would be a good idea to include at least a single sentence somewhere near the top explaining what the heck a glass fish is.

trashcluster 6mo ago
A java framework, like Springboot
- angelaguilera 6mo ago
  Nope. From the glassfish.org web page: "Eclipse GlassFish is a lightweight yet powerful open-source application server that fully implements the Jakarta EE platform."
- gertrunde 6mo ago
  er... surely it's a Java application server? (i.e. in the same space as Jboss/Wildfly, WebSphere, etc) Historically, it was also the reference implementation application server for J2EE.
  - chasd00 6mo ago
    I thought that was Tomcat or was Tomcat just the servlet reference implementation, i can't remember. App servers like Glassfish were what operations people used before the concept of "devops". Developers wrote the code and admins/ops deployed the code on app servers like Glassfish. Devops was supposed to put developers in charge of the whole stack but every enterprise i've seen have a dedicated devops team that manages AWS/Azure/GCP and separate developer teams who write the code. So it's pretty much the same it's always been ironically.
    - henk53 6mo ago
      > 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.
- ondromih 6mo ago
  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.
stavros 6mo ago
Exactly, I had to read way too far before giving up because I have no idea what Glassfish is.
cess11 6mo ago
In the Java world it is rather common to use something called application servers. These are meta-applications that provide your applications an environment with things like database abstractions and the like, as well as admin interfaces. It solves some of the same problems you might reach for Kubernetes or OpenShift for, your application gets access to external resources in structured ways and you get to look at dashboards. GlassFish is an example of such an application server. WildFly is more common, and is the artist formerly known as JBoss. If you have some knowledge in the enterprise Java ecosystem you can quickly and easily (or maybe not, it depends) deploy your creations into these.
pvaldes 6mo ago
> what the heck a glass fish is. In Biodiversity, a glass fish includes a few group of Asian fishes that show crystal transparent bodies to hide from predators. Specially when young. They are vertebrates that evolved transparent muscles. Two gens are kept in aquariums: Parambassis ranga and several ghost catfish from gen Kriptopterus. We can assume that the programmer likes aquariums. The word Yakarta is not random, as is related with the catfishes distribution.
- cess11 6mo ago
  Jakarta was chosen by the Eclipse Foundation because it is the largest city on the island of Java, and Oracle is virulently litigious around the Java trademark. https://www.theregister.com/2018/03/04/java_ee_is_now_jakarta_ee/ https://www.theregister.com/2018/03/04/java_ee_is_now_jakart...
znort_ 6mo ago
probably this article isn't for you if "glassfish" isn't a familiar term. if curious (or fomo) it would have taken you about 15 secs to find out what glassfish is, which is still probably 15 less than what you wasted on this mini rant. from there it's up to you to go down the rabbit hole.
ondromih 6mo ago
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.
riffic 6mo ago
obviously you're supposed to know what everything is ahead of time on orange site.
- deleted 6mo ago
  [deleted]

ysleepy 6mo ago

(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.

zvqcMMV6Zcr 6mo ago

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.

bzzzt 6mo ago
Spring and JEE (or Quarkus) are very similar, from the viewpoint of an application developer both have the same JAX-RS REST and Hibernate/JPA API's. IMO the kind of person who only knows Spring and doesn't understand modern JEE is exactly the kind of person you don't want to recruit.
- gadflyinyoureye 6mo ago
  Spring won. Why would anyone want to learn the standard aside from it being a standard that few people use? Spring itself is a wildly adopted standard. It is a semi open standard in that anyone can use it freely, but in that it's not supposed to be implemented by others. The same is true for Micronaught or Quarkus. Learn the frameworks. But they are not a new open standard.
  - pjmlp 6mo ago
    Except people keep forgetting they implement the standards on their very foundation.
  - henk53 6mo ago
    > 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?

sgt 6mo ago

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.

Cthulhu_ 6mo ago
I love the irony / (perceived) sarcasm in your comment, :p.
ondromih 6mo ago
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.
- sgt 6mo ago
  Fair enough. If OmniFish can properly support it and help it continuously develop it will have potential for adoption by even those using Spring.
reactordev 6mo ago
>”latest Java technologies like Spring Boot.” Which are already old enough to drive… latest my ass.
- sgt 6mo ago
  I hear you, but there's genuine excitement still about Spring Boot and related technologies. See [1] Spring Cloud. [1]https://spring.io/projects/spring-cloud https://spring.io/projects/spring-cloud

boomskats 6mo ago

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.

philipwhiuk 6mo ago

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).

ondromih 6mo ago
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.
- unscaled 6mo ago
  And this makes the entire application server and Servlet model the wrong abstraction. Microprofile simplifies things, but in the end I feel Java EE is just pushing the wrong abstractions here. Cloud native microservices are meant to be small, and receive their "cloud native dependency injection" through standard Unix interfaces like environment variables standard input and output, command line arguments and sometimes files. Cloud native apps are close in spirit to twelve-factor applications (which is a stricter rendition of that). Jakarta EE, even with its latest updates, comes from a different world. Standardized library API with interchangeable implementations that are injected by the application server. But wait! We flip the script by embedding the application server inside a fat JAR and shipping everything in a single docker/OCI container. A lot of the stuff that used to happen in the application server (load balancing, shared connection pooling, configuration, service discovery, service bus) happens now at the cloud infrastructure level. You can still use a MicroProfile-based framework, and Quarkus (which is based on MicroProfile) is very popular nowadays, but once you went along with a certain framework, you're not very likely to replace it. Standardization was the selling point of Java EE in the past, but in the microservice world when you're only betting a smallish microservice on Framework X, people are not so concerned about putting all their eggs in one basket anymore.

whartung 6mo ago

This is good to hear. 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.