What You Need to Know About Jakarta EE vs Spring

I think of Jakarta EE as that 'classic' set of rules and tech that big businesses might need, like stability and support for legacy systems. It was a time when everything big Java was all about enterprise-grade solutions. On the other hand, Spring started as an alternative that broke away from that rigid structure. You don't need to master Jakarta EE to get by with Spring, as Spring often simplifies the process by telling you what you need without making you dive too deep.

Jakarta EE is more about the specifications; it initially comes from the days of Java EE that Oracle rebranded. While some companies might still rely on Jakarta EE for stability, most modern Java applications, especially in dynamic environments, tend to gravitate towards Spring due to its flexibility and rich ecosystem. If a job listing requires extensive knowledge of JEE stack, it's usually a red flag—indicating it might be using outdated tech.

You're right that Jakarta EE provides a bunch of APIs, but it's not a framework in the same way Spring is. Spring was designed to be lightweight and offer flexibility, often standing in contrast to the heavier Java EE (now Jakarta EE) model. You can dive straight into Spring without needing exhaustive knowledge of Jakarta EE; just focus on the parts of Jakarta that Spring uses when you're learning—it will make things easier. When you get deeper into Spring, you'll start seeing how it connects with those Jakarta EE concepts.

To clarify, Jakarta EE is indeed a specification, and while it informs framework design, it isn't a framework itself. You can absolutely learn Spring without a thorough grounding in Jakarta EE. Just be aware that Spring integrates a few Jakarta APIs, like JPA for persistence and Servlets for web applications, but it abstracts away much of the underlying complexity. It’s common for people new to Java to choose to learn Spring right away without delving into Jakarta EE first.