I see lots of stuff built in subsets of the standards. JAXRS and CDI are quite nice, and there are lots of better thought out Spring alternative libraries. Also we have microprofile, Quarkus, Dropwizard, and others that make use of the same standards.

I bet big on Java/Jakarta EE, and the open source application server WildFly, years ago when the web version of Calcapp was born in 2014. I have been very happy with that decision. JAX-RS is a great way to build annotation-driven REST web services with very little boilerplate. WildFly (the open source version of JBoss EAP, essentially) is actively developed by Red Hat, starts quickly and is easy to work with. And the modern incarnation of Java -- with streams and lambdas -- is a great fit for what we do (building a compiler).

The only decision I have come to regret is using JPA, which is short for Java Persistence API (a specification for an ORM -- an Object-Relational Mapping), and where the most famous implementation is Hibernate. As far as ORMs go, Hibernate is probably fine, but I wish I had considered using something more light-weight and closer to the underlying database. As things stand, JPA mostly gets in the way, and I have had to resort to "native queries" (SQL) for our most performance-sensitive code paths.

I don't regret choosing JPA, as much as I regret choosing an ORM.

Also, as others have alluded to, Java is a stable choice. At the same time I chose Java EE and PostgreSQL, I chose AngularJS for our front end, which has been fully superseded by modern versions of Angular. We'll need to spend lots of time replacing AngularJS with React or Angular (we haven't decided yet), so that decision didn't really pan out.

On the server, though, I couldn't be happier with Java/Jakarta EE and PostgreSQL.

Probably not much - but bear in mind that there's so much Java out there that there are bound to be a few backwaters doing weird things as well as a huge pile of legacy code that will benefit from the update (probably not as big as the pile of legacy code that will never get enough love to get updated!)

I haven't personally seen any green field Java EE code in the last 10 years or so!

Edit: Since I got downvoted for this (I would have thought) innocuous observation, I'll add the clarifying observation that Java is thriving. I'm specifically talking about Java EE, and Java EE as a platform at that, not as one-of-many libraries supporting the various other platforms.

I mean I also think you are right. I will observe that Java EE is now Jakarta EE. It is important because it means not much money is to be made by "Java EE" now, So Oracle has dumped it to Eclipse foundation as Jakarta EE.

It has also been sliced and diced in to multiple profiles, popular among them is Microprofile. It can be implemented with Apache tomcat instead of heavier Websphere/ Weblogic etc.

Another thing that happened is container term which in Java world would be Servlet/EJB containers is now associated with Docker containers. And Java enterprise containers fell out of fashion.

All these factor led do Java/Jakarta EE being also ran.

And there I was patting myself on the back for not calling it J2EE ;)

> I haven't personally seen any green field Java EE code in the last 10 years or so!

I’m sure you have. Nearly everyone is using JPA and Quarkus is using JAX-RS via RESTEasy and other parts of the microprofile part of EE.

To reiterate:

> I'm specifically talking about Java EE, and Java EE as a platform at that, not as one-of-many libraries supporting the various other platforms.

It is a set of standards. Most modern frameworks like Quarkus implements a subset of it (microprofile), while a large part of Spring is also an implementation of it/at least spring understands concepts out of it.

So yes, it is still used very extensively, though I don’t think that the old application container model is used for new apps anymore.

If you want to build anything with reliability, testable and amazing echo system j2ee is the way to go.

I was a skeptic myself always thinking it's too heavy and too large and too slow, but after fate handed me a codebase of j2ee platform and seeing how reliable and no effort is put into maintaining it rather just focus on the application logic.

I would always chose java for any software that's expected to last 10 years plus and should work reliably.

I build an indie app fully with Jakarta. Source code on Github if you are curious. https://nocodefunctions.com/

I had never built a JVM app and needed to, evaluated a bunch of technologies, and went with Jakarta EE + Eclipse MicroProfile on Quarkus.

Believe it or not, it's a very pleasant and modern experience and the technology is easy to understand (except for CDI, that took a while).

I didn't like that all the other frameworks had invented their own ways of doing things. Having a standard/specification with a voting committee from multiple organizations seems much more rational to me.

Certainly with parts of it? I use JAXRS quite a lot, it's great.

Aren't Quarkus (and possibly other frameworks/libs) built on top of it?

Quarkus uses the Eclipse Microprofile API, a subset of Jakarkta EE API optimized for microservices. It uses Smallrye for the implementation of the API.

It does use other parts like RedHat’s RESTEasy implementation of JAX-RS.

Yep, still typical in many Fortune 500 consulting shops.

Think of it as bridge/connector to old and new components of infrastructure. So yes, it is used in lot of places