EclipseLink 5.0.0 has been released, delivering Jakarta Persistence 3.2 support as part of the Jakarta EE 11 generation.
What's new in 5.0.0
The headline is complete Jakarta Persistence 3.2 compliance, which brings a rich set of language-level improvements. Java record types are now first-class @Embeddable classes, a quality-of-life win that removes a persistent pain point for teams adopting records in their domain model. The temporal story gets a needed modernization: java.time.Instant and java.time.Year gain first-class mapping support, and the old Calendar, Date, @Temporal, and TemporalType APIs are formally deprecated in favor of the java.time API — which has been available since Java 8 and really should have been the standard path years ago.
JPQL picks up UNION, INTERSECT, and EXCEPT (long-missing from the spec), plus CAST, LEFT, RIGHT, and REPLACE, a || string concatenation operator, and ID() and VERSION() functions. These aren't exotic; they're the kinds of things developers have been working around with native queries for years. If you use criteria, the Criteria API gains CriteriaSelect, EntityType-based joins, and new getSingleResultOrNull() - likely a welcome addition that replaces the try/catch NoResultException pattern. Static inner classes are now valid entity and embeddable types, and PersistenceConfiguration provides a programmatic path to building an EntityManagerFactory without a persistence.xml, which matters for test and embedded scenarios.
On the infrastructure side: BOM artifacts are introduced for cleaner dependency management, JPMS module descriptors got fixes and cleanup (if that is something you use), deadlock detection was improved, and legacy code using java.util.Vector internally was cleaned out. This looks like a solid, well-scoped major release, as one might expect. Or one might not, if you're not aware of some of the less-talked about corners of the Java ecosystem: very strong but generally seen as part of monolithic deployments rather than "popular tools."
EclipseLink vs. Hibernate
The two implementations share a spec but diverge in character. Hibernate historically drove many of the features that eventually become JPA standards. It has a large, vocal community, extensive documentation, an active blog, and deep integration with the Spring ecosystem. When you add spring-boot-starter-data-jpa to a project and don't otherwise configure anything, you get Hibernate. For a significant part of the Java developer community, JPA is Hibernate, and vice versa.
EclipseLink's strength is different. It is the reference implementation of the specification, and has always been, thanks to its TopLink heritage. This means it tends to be more conservative, more spec-literal, and less inclined toward proprietary extensions (though it has them: @AdditionalCriteria, fine-grained caching controls, EIS persistence, and the MOXy XML/JAXB layer). EclipseLink tends to lean in more towards Jakarta EE application servers more uniformly than Hibernate's more Spring-centric defaults, which matters in environments where a container is doing more of the lifecycle management.
Lifecycle management is the lever for Jakarta EE. Most developers want end-to-end control of their application, from configuration to setup to deployment to everything, and Jakarta EE is designed to let those who're good at configuration handle configuration, the same for deployment: you declare that you need a given resource, you acquire it, you use it, you release it. Spring is able to give you this model, but it's more the "traditional" design: you control everything. Many developers like control, as it turns out, which is why they run everything on their local PCs - and we've changed a lot of deployment models to cater to this preference. More on this in the next section.
The tradeoff, historically, is that EclipseLink's community engagement feels thin. Blog posts, Stack Overflow answers, and conference talks on EclipseLink are a fraction of what Hibernate generates. Version cadence and documentation updates have lagged. There's no EclipseLink equivalent of the Hibernate team's consistent stream of tutorials and upgrade guides. You can stock a library shelf with Hibernate books: for EclipseLink, it's much more slim pickings. You end up working with the JPA standard (not a bad thing) and working out what EclipseLink does differently than Hibernate more than anything else, because the documentation silently assumes Hibernate.
The silent majority problem
Here's what makes EclipseLink interesting as a case study, though: by the metrics we can measure - GitHub stars, Stack Overflow tags, blog posts, websites dedicated to support, conference talks - it looks marginal. But by the metrics we can't easily measure - enterprise deployments in Oracle, IBM, and Jakarta EE-certified stacks - it's probably not marginal at all. If you're using an application server other than JBoss/Red Hat, you're likely to be using EclipseLink unless you shoehorn Hibernate in anyway.
This feels a lot like the JSF situation JavaServer Faces (or, I guess, Jakarta Faces now) has had decades of vocal critics and a steady drumbeat of blog posts declaring its irrelevance, while a substantial slice of enterprise Java - insurance companies, government systems, banking back-offices - have apparently kept running it without generating any public signal. The community's apparent consensus ("JSF is dead/dying/irrelevant") and the actual deployment reality diverged badly, because the people running JSF in production weren't the people writing blog posts or attending conferences. They were, characteristically, the people not talking about their stack at all. And you can see this in seeing how JSF vendors still have relatively regular releases - to almost no public acclaim and interaction.
EclipseLink occupies a similar niche. The organizations most likely to use it are the ones running managed Jakarta EE servers - Payara, OpenLiberty, WebLogic - under enterprise software procurement processes that do not produce (or even allow, in many cases) blog posts. They chose EclipseLink because their vendor supports it, because their server ships with it, or because they have institutional knowledge from J2EE-era TopLink deployments. They're not going to tweet about it. (And, again, in some cases they're not allowed to tweet about it.) When the EclipseLink project ships the next version, they'll eventually upgrade, file a ticket if something breaks, and otherwise generate no observable signal.
The question this raises is genuinely tricky for anyone trying to gauge ecosystem health: where are the talking voices, and why? In any mature technology space, the most active public voices are the ones with something to sell - training, consulting, tooling - or the ones solving genuinely novel problems. (Or sites like this one, who might hope to benefit from those talking voices.)
Enterprise-stable technology running steadily in production produces little smoke like that: it's not accompanied by fury or chatter or, for that matter, constant discovery. This creates a systematic bias in how we perceive "community health" that's worth being explicit about. A quiet project isn't necessarily a dead project. Sometimes it's just a project that has found its users, and those users are busy running production systems rather than writing about them.
And that's why we get releases like new implementations for EclipseLink and Mojarra.