Juergen Zimmermann opened SPR-17561 and commented
Spring Context Support is using javax.mail:javax.mail-api and javax.activation:javax.activation-api. Meanwhile there is com.sun.mail:jakarta.mail and com.sun.activation:jakarta.activation.
Affects: 5.1.3
Comment From: spring-projects-issues
Juergen Hoeller commented
We generally compile against baseline APIs, not necessarily against the latest... except for cases where we need (optional) dependencies on newer interfaces, like with Servlet 4.0 where we compile against 4.0 while retaining 3.1 compatibility at runtime. From that perspective, I see us hanging on to the common EE 7/8 API artifacts as a baseline for the time being.
Is there a specific reason why you'd like us to switch to the Jakarta-provided artifacts? A concrete application project can bring in the Jakarta variant at runtime in any case since we are not enforcing the Oracle-provided artifacts, in particular not for optional dependencies, just using them for compilation purposes as the common reference APIs out there.
Comment From: spring-projects-issues
Juergen Zimmermann commented
OK, got it. I thought that you are compiling against the latest API versions.
Comment From: pontello
@spring-issuemaster , what is the correct way to tell spring CDI that jakarta.inject.Inject plays the same role as javax.inject.Inject?
I've researched a lot aboud this topic and haven't figured out an elegant solution for it. Please note that @AliasFor isn't an option because I can't annotate jakarta packages.