jakarta.inject support

[cogman]

Jakarta is coming to cause headaches for all :)

It would be nice if Dagger could support processing Jakarta inject annotations as well as javax inject annotations. That would prevent us from potentially having to write a cross injection system constructor like

@Inject
@jakarta.inject.Inject

Fortunately, they don't share a package and it looks like jakarta pretty much only changed the package name.

[bcorso]

I don't know what Jakarta is , but do you know why it is defining its own jsr330 annotations rather than using the standard javax.inject.* annotations?

Have you tried filing a bug with them to switch?

[tbroyer]

@bcorso This is the new home for Java EE! Oracle killed javax.* and the Java EE name and forced Eclipse Jakarta to rename to jakarta.* and Jakarta EE (also applies to javax.servlet et al.)
This is a copyright and Oracle-bullshit issue, there's no way backwards 🤷‍♂️

[bcorso]

Oh... wow. Okay, yeah looks like we'll have to support all of jakarta.inject then.

[twillouer]

Hi, with Jersey 3.0 it will be mandatory I think :)

[overheadhunter]

Just a thought:

Instead of supporting both, javax.inject and jakarta.inject, would switching to solely supporting jakarta.inject be an option? For downstream projects this means s/import javax.inject/import jakarta.inject/g. Nothing particularly difficult, but still technically an API-breaking change.

If this was acceptable, implementing this change wouldn't increase the complexity in Dagger.

[Chang-Eric]

Thanks for the idea, but for a large breaking change like that we'd have to support both at the same time for some (long) period of time to let people incrementally migrate.

[overheadhunter]

I just learned from the discussions in this PR, that jakarta.inject before version 2.0.0 still uses the old package name. So in fact this would be no breaking change when simply changing the dependency to jakarta.inject:jakarta.inject-api:1.0.3. These are these consequences:

downstream project	depends only on Dagger	depends on Dagger and javax.inject
uses module path	✅ Can now use reliable Automatic-Module-Name	⚠️ Split package
uses classpath	✅ No change	✅ Classes from both jars are identical by design, classloader may choose arbitrarily

The split package is only a virtual problem, since projects relying on the module path will avoid any such configuration. Nevertheless it should be documented.

It is even possible to have jakarta.inject:jakarta.inject-api:1.0.3 and jakarta.inject:jakarta.inject-api:2.0.0 on the module path at the same time, since the former uses java.inject (sic! as per JEP 200) and the latter jakarta.inject automatic module names.

[overheadhunter]

Just to confirm my previous suggestion: I just replaced javax.inject with jakarta.inject-api version 1.0.3 via dependency management in a multi-module project structure. No changes required. Works flawlessly on both modular and legacy projects.

Can you please consider this as a preliminary solution, until a "real" switch to jakarta namespace can happen eventually?