Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

foojay.io

Post reply on HN
Print view View original

41–49 of 49 posts

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

#41

Post by freedomben »

henk53 wrote: post #18
gadflyinyoureye wrote: post #15

Earlier quoted context omitted.

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.

> 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?

Yes please, though this is largely driven by my personal dislike of Spring Boot. The bloat and magic sucks so much of the joy out of programming to me. That said, I never lived in Spring Boot exclusively. I've heard people say that it's an "all in" kind of thing and once you go all in and learn the thing really well, you start to like it.

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

#42

Post by henk53 »

gadflyinyoureye wrote: post #33
bzzzt wrote: post #19

Earlier quoted context omitted.

There's nothing to be gained by picking a winner, especially if it doesn't really matter because the important APIs are the same. Newer frameworks like Quarkus are specifically built for container usage and applications built with it are a bit faster and smaller than Spring boot.

I'm saying the spec lost to Spring. There are many historical reasons for the loss, but Spring won. It looks like the industry is moving away from architectures like EE. The desire now is more like a Go deployment: single, self contained deployable. There are make frameworks that support this goal. Maybe EE is one of them, but it's not essential like it was in the early 2000s.

> single, self contained deployable

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.

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

#43

Post by whartung »

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.

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

#44

Post by RickJWagner »

zvqcMMV6Zcr wrote: post #5

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 y…

I used to work for Red Hat middleware, and I love JBoss. Bickering is not why Spring did so well.

Spring just made things easy. It also had only one implementation, so you couldn’t be confused because a deployment descriptor worked on one platform and not another. Some random blog post on setup always worked when Spring was in use. If you were following a WebLogic cookbook, good luck on Websphere.

In the end, Easy always wins. Make something hard easier to use, the world will beat a path to your doorway.

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

#45

Post by sgt »

reactordev wrote: post #32
sgt wrote: post #30

Earlier quoted context omitted.

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

Excitement is hardly the term I would use… it’s also old. It’s also outdated. Spring is done without corporate sponsorship or leadership. It died during the pivotal/vmware/handoff days.

In your opinion, is there a better option than Spring Boot right now in the Java ecosystem? For what it does, at least. I know there are a lot of libraries and frameworks out there but not all are as complete as Spring Boot.

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

#46

Post by reactordev »

sgt wrote: post #45
reactordev wrote: post #32

Earlier quoted context omitted.

Excitement is hardly the term I would use… it’s also old. It’s also outdated. Spring is done without corporate sponsorship or leadership. It died during the pivotal/vmware/handoff days.

In your opinion, is there a better option than Spring Boot right now in the Java ecosystem? For what it does, at least. I know there are a lot of libraries and frameworks out there but not all are as complete as Spring Boot.

Ugh, I’d rather use Micronauts or Quarkus than Spring… but enjoy your AutoWiredBeanPreProcessorBeanInterface.

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

#47

Post by antonvs »

philipwhiuk wrote: post #36

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 appli…

The model made more sense before containers existed. Basically, Java tried to become a complete platform for application deployment, at a time when there weren’t many other good solutions to that.

However, the problem with that is that it requires writing everything in Java - heterogeneity breaks the model. A language-agnostic solution like containers was bound to win out, it’s just that nothing remotely close existed at the time.

Keep in mind a lot of this was developed even before VMs were commonplace. The first true, usable VMs for x86 were released in 1999, four years after Java’s debut.

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

#48

Post by unscaled »

sgt wrote: post #30
reactordev wrote: post #28

Earlier quoted context omitted.

>”latest Java technologies like Spring Boot.” Which are already old enough to drive… latest my ass.

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

I remember all the excitement about Spring Cloud... But that was back in 2017.

I never thought of Spring (or Spring Boot) as good technology, but even for the right audience Spring boot is as exciting as React is exciting for frontend developers or C is exciting for kernel developers. It's a pretty established technology that was new and cool at one point and has just become commonplace and boring for better or worse (I would argue worse, but that's just me).

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

#49

Post by unscaled »

ondromih wrote: post #38
philipwhiuk wrote: post #36

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 appli…

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 dro…

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.

Post reply on HN