|
Java's been my bread and butter for three decades now, and I often wonder this myself. Virtually all of the job postings that I ever see are using Spring, and I don't have a single known person in my professional network who is using Jakarta EE anywhere. MAYBE some proof-of-concepts here and there with Quarkus, which I believe is technically a spin on Jakarta EE "microprofile". But no one is running an old-school WebLogic, WebSphere, Glassfish, etc application server. My sense is that this is confined to legacy systems in very large companies, and MAYBE a bit of greenfield popularity in Europe. This question gets very confusing though, because I believe that a lot of developers love to purposefully obfuscate it. The terms "Java EE" and now "Jakarta EE" can be looked at in two different ways: 1. A collection of various API standards, that may be implemented to some degree and/or extended by various libraries. 2. Developing against an all-inclusive application server such as WebLogic, WebSphere, Glassfish, etc... that comes with implementations of all those API's. Where your application is configured to rely on those implementations that come with the application server, rather than bundling up its own dependencies itself. The thing is, when people ask "Who uses Jakarta EE?", they are almost always thinking about #2 there. Who in 2023 is still developing to WebLogic, WebSphere, Glassfish etc as a target environment, and relying on the library implementations that come with that server? I THINK the answer to that is "pretty few people". However, people who have pinned their careers to those stacks, and/or sticklers who love to be contrarian, often bait-and-switch with the #1 definition above. They will point out that Spring uses some implementations of some of those Jakarta EE specs, and therefore "Spring IS Jakarta EE" or at least "Spring depends on Jakarta EE". That's not really good faith, though. One of Spring's strengths is that it can INTEGRATE with virtually everything. But that doesn't mean that much of anything is a requirement for using Spring. For example: * By default, a Spring Boot application with the "web" starter pack embeds Tomcat for HTTP services. So people can say that's "using the Servlet spec". Except that Spring doesn't necessarily have to use Servlets. You can override that Tombcat dependency with Netty, which is not Servlet-based and not part of Jakarta EE at all, and probably not even have to change any of your code. The old-school Servlet spec is neither here nor there to writing a modern Spring controller class. * By default, if you use Spring Data with the "JPA" starter, then you are using Hibernate, which is an implementation of the JPA spec. However, you certainly don't HAVE to. There are flavors of Spring Data that provide similar functionality, backed by plain JDBC. Not to mention spins for MongoDB, Redis, and other databases that are completely outside the scope of Jakarta EE. So on and so forth. A Spring application MIGHT be using a Jakarta EE API somewhere, but by no means does it HAVE to, and they often don't. So in my opinion, it's extremely disingenuous to take that "#1" definition, of Jakarta EE being a loose basket of API's, and use that to give people the impression that the "#2" definition of Jakarta EE as an old school fully-integrated app server is more widely used today than it actually is. |