What is the timing for the switch to the jakarta.* namespaced dependencies in JEE9? Is there a version I can use or build that's made that change?
Comment From: jhoeller
We have no immediate plans to make such a switch, and also no plans for an early access branch. Our upcoming Spring Framework 5.3 generation will be compatible with Java 8+ and based on the javax-namespaced EE 8 APIs still, for immediate use in current production environments. Beyond that, Spring Framework 6 is likely to adopt the jakarta namespace at a later point.
The jakarta-namespaced APIs are not final yet and we expect a long time to go by before all major providers support them in production releases. We not only need Tomcat, Jetty and Undertow but also EclipseLink, Hibernate ORM and Hibernate Validator to provide major releases here, plus several special-purpose providers and libraries, before we can consider a version of Spring based on jakarta-namespaced APIs. Since there is no relevant value add in EE 9's namespace change per se, backwards compatibility with existing application servers and persistence providers through the javax namespace is more important to us.
That said, if you have a production-targeting stack scenario where our continued use of the javax namespace is an issue, please elaborate. We are aware that the upcoming Tomcat 10 cannot be supported quite yet and recommend sticking with Tomcat 9.0.x (which is feature-equivalent with Tomcat 10, just still based on the javax namespace) for the time being.
Comment From: krzyk
HIbernate validator 7.x made a switch to jakarta.* namespace and now I have issue I have to choose if I want hibernate validation to work or Spring validation.
Isn't it really possible to support both javax. and jakarta. namespace? Or is there a workaround for this I could implement in my code?
Comment From: andrei-ivanov
You can use HV 6.2: https://in.relation.to/2021/01/06/hibernate-validator-700-62-final-released/
Comment From: krzyk
yes, but I would need to rename all packages jakarta.validation back to javax.
Considering that the release was in December I think it would be good to add both jakarta and javax packages in the validation.
I was hoping: Copy that bean from Spring source, and rename javax there to jakarta and it will magically work :)
Comment From: jhoeller
I'm afraid this won't work in a per-spec fashion, at least not for us as framework provider. We need to make the move to Jakarta EE 9 and the jakarta namespace for all EE APIs at the same time, otherwise it'll just be a mess in terms of API interoperability and also in terms of commercial support. You may copy and paste individual classes on your own, of course, but this is not recommended and we won't officially support this for the time being.
It is generally understood that the Eclipse-Foundation-enforced namespace switch in Jakarta EE 9 is a huge breaking change that will take years for the ecosystem to broadly adopt. That's exactly why many product providers chose to release two versions in parallel, e.g. Tomcat 9 vs 10, Jetty 10 vs 11, and also Hibernate Validator 6.2 vs 7. Each respective pair of releases is largely feature-equivalent, just differing in the package namespace that those releases work with. Making use of those latest javax-based releases is what we strongly recommend in the meantime, before Spring Framework 6 and Spring Boot 3 will make the general upgrade to Jakarta EE 9+ next year.
Comment From: Sudha-84
Is there any ETA on this? I greatly appreciate your response.
Comment From: jhoeller
No ETA yet, I'm afraid, just rough guidance that Spring Framework 6 and Spring Boot 3 will become generally available in 2022. We'll certainly release a first 6.0 milestone in Q4 2021 still but the final production releases are at least a year away. For the time being, we aim to support the latest javax-based versions of all common open source projects in our actively developed Spring Framework 5.3.x line, with Boot 2.4 and 2.5 (and also the upcoming Boot 2.6 and 2.7 releases) building on it.
Please note that this is in alignment with the rest of the open source ecosystem and also the Java industry overall. As outlined above, while some open source projects have early Jakarta EE 9 based releases already, they keep mainline Java/Jakarta EE 8 based releases in parallel which are feature equivalent and will be maintained for a long time still. This is also the case for the recently released Hibernate ORM 5.5, for example. We strongly recommend staying on EE 8 for the time being.
Comment From: Sudha-84
Thanks for your response
Comment From: mckramer
@jhoeller from a hibernate-validator perspective, that artifact has actually already upgraded to jakarta dependencies in 6.1.x, which Spring has moved to already. Maybe that was not known, but Spring does have transient dependencies on jakarta.* now.
spring-framework javax validation-api@2.0.1.Final spring-framework hibernate-validator@6.2.0.Final
hibernate-validator jakarta.validation-api@2.0.2
This introduces a conflict as spring sits today. Is that intentional?
Comment From: spencergibb
Hibernate Validator 6.x will keep the javax. packages while Hibernate Validator 7.x moved to the jakarta. packages.
From the article linked in a comment above https://github.com/spring-projects/spring-framework/issues/25354#issuecomment-812572313
Comment From: MCMicS
@mckramer Hibernate 6.x still use javax. The 2.0.2 version of jakarta.validation-api contains the javax packages. it will be renamed with 3.x version
Comment From: jhoeller
@mckramer It's confusing, unfortunately. Jakarta-provided artifacts may contain javax. or jakarta. APIs, depending on the version.
Jakarta EE 8 is effectively a repackaging of Java EE 8, preserving not only the javax namespace but also the existing major version numbers of the individual APIs (e.g. bumping the Validation API from 2.0.1 to 2.0.2), remaining compatible with existing API usage at the source and binary level, just suggesting different Maven coordinates for the build artifacts.
Jakarta EE 9 and higher actually repackage the APIs into the jakarta namespace at the Java interface level, forcing all downstream projects to adapt their code. That's the new baseline that we will pick up in Spring Framework 6 and Spring Boot 3, supporting common open source projects which provide established versions on that baseline by then (e.g. Tomcat, Jetty, Hibernate but possibly dropping support for a few other servers and libraries which might remain stuck on EE 8).
Comment From: mckramer
Right, the concern isn't with the change in "api", but rather that Hibernate >= 6.1.x uses the jakarta artifact. Despite it still being the same package/classes under the covers, it is a separate artifact. As a result, the javax validation-api AND jakarta validation-api jars can both end up on the classpath of the final application. Resulting in duplicate classes.
Applications then are required to try to manage exclusions across many transient dependencies to avoid both jars from being resolved.
The answer may simply be that Spring has a preference to the Jakarta EE 8 packages (as opposed to Java EE 8), and apps should manage as such? Spring generally simply defines the javax validation-api deps as optional, but contains managed versions for both artifacts.
Comment From: SushmitaGoswami
Is there any updates on this? May we know when will spring move to jakarta? Any approximate quarter?
Comment From: martin-g
Spring 6.x moved to Jakarta APIs. M1 has been released several months ago.
Comment From: sbrannen
@SushmitaGoswami, see related blog post:
https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6