jakarta.inject support

@Inject

Jakarta is coming to cause headaches for all :)

It would be nice if Guice 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.

That's not a small undertaking - whole library sprinkled with java.inject namespace. Thinking about it - would an acceptable solution to have 2 libraries - guice-javax and guice-jakarta , and make them coexists somehow? (thinking out loud)

You can use the guiced-ee artifact for jakarta namespacing across the board

https://mvnrepository.com/artifact/com.guicedee.services/guice

Are there any plans to look into support for this?

I would be willing to contribute, maybe even with a small team.

@GedMarc

@GedMarc Check this out, yo.

Guice's greatest virtue is its agility and that it is a DI library by itself with no frills added. Other DI and CDI solutions are fullstack If you want to use more modern application servers ( or other solutiones....) , on many occasions are forced to do a full stack migration. In itself a migration to , for example, toSpring, Micronaut, Quarkus is a full stack migration generating complicated dependencies that can condition the evolution of the applications.....

Indirectly, not supporting this small functionality is forcing developers to do full stack migrations and it's not easy to get out of there! Reconsider!

We need this.

Bump on this, still not resolved. Is there any workaround?

I did an automatic repackage of guice 5.1.0 (with tomcat migration tool) and published it yesterday into maven central (as rc.1 for now). Repackaged version use jakarta.inject, jakarta.servlet and jakarta.persistence.

Conversion performed on source jars (loaded from maven central) which are compiled then, so sources and javadoc are aligned in maven central publication. Pom and manifest files were manually rebuild (to replace dependencies and fix OSGI declarations). Struts2 and spring modules are not included (I doubt someone needs it).

Those who interesterested, please help me test it.

About 3rd party libraries: there would, of course, be problems with 3rd party libraies using javax.inject annotations: migrated guice would not see these annotations causing errors (e.g. not found constructor because of wrong annotation). In my libs I simply replaced all javax.inject.Inject annotations with gucie native annotations (so it could work with both javax and jakarta guice versions).

FYI all, I'm going to take some time early next week to fix this for core Guice.

I am still against outright forking the servlet extension into the jakarta namespace though, and will gladly welcome (and encourage) any community members that want to fork the servlet extension, fix its warts, and become the "official owners" of it.

@mcculls

Hi folks -- I have some changes prepared to support this for core Guice. However, the Dagger folks mentioned that they were informed of some issues related to supporting both javax.inject & jakarta.inject at the same time -- see google/dagger#2058 (comment). The TL;DR as best I can make out is:

javax.inject (from the javax.inject:javax.inject:1 maven coordinates) is old and doesn't have a "Automatic Module Name"
Jakarta folks re-published the javax inject APIs with a module name under jakarta.inject:jakarta.inject-api:1.0.5, but then went ahead and changed the packages to jakarta.inject but kept the jakarta coordinates and just incremented the version, to: jakarta.inject:jakarta.inject-api:2.0.1.
As a result, folks wanting JPMS-compatibility cannot use the original javax.inject:javax.inject:1 artifact (because it has no module name), and cannot use the jakarta.inject:jakarta.inject-api:1.0.5 and jakarta.inject:jakarta.inject-api:2.0.1 at the same time, because they're the same thing artifact (just with different versions). This means that folks wanting JPMS compatibility cannot reference both javax.inject and jakarta.inject at the same time.

How much of an issue is this for folks? My plan is basically to keep the javax.inject:javax.inject:1 dependency, introduce a new jakarta.inject:jakarta.inject-api:2.0.1 dependency, and have Guice depend on both the javax.inject namespace & the jakarta.inject namespace. But IIUC, that may break strict JPMS compatibility.

I'm open to ideas from folks more familiar with Maven about how to handle this.

(@mcculls FYI)

Why attempt to support both namespaces simultaneously, as opposed to just declaring Guice version X.Y.Z only supports the jakarta.inject namespace only?
Are folks wanting to intermix usage of both namespaces simultaneously?

@norrisjeremy

@norrisjeremy -- For one, Google has quite literally millions of files referencing javax.inject. It isn't feasible to just up and say "switch'm all to another package". I wouldn't want to demand that from any other users either. Even if a migration were to happen, it would need to be incremental -- we can't just say "switch your entire codebase in order to use the new version".

One possibility here is to introduce a separate published artifact with a -jpms-compat suffix, and that artifact could potentially shade the javax.inject references. A naive shade would produce some awkward APIs, where Binder (for example) would have toProvider(Class<? extends shaded.javax.inject.Provider>)-like APIs. (The toProvider methods in Binder are also a problem in general for supporting jakarta.inject, so maybe there's another solution that could deal with those too.)

On Tue, 25 Apr 2023 at 17:39, Sam Berlin ***@***.***> wrote: @norrisjeremy <https://github.com/norrisjeremy> -- For one, Google has quite literally millions of files referencing javax.inject. It isn't feasible to just up and say "switch'm all to another package". I wouldn't want to demand that from any other users either. Even if a migration were to happen, it would need to be incremental -- we can't just say "switch your entire codebase in order to use the new version".

Old apps can still use the current/old version of Guice. When an app is ready to switch to Jakarta it will bump to the new version of Guice that is based on Jakarta-inject 2.0.1 I guess you don’t want to maintain two major versions of Guice. But supporting both Javax and Jakarta simultaneously would be more work in my opinion.

…

One possibility here is to introduce a separate published artifact with a -jpms-compat suffix, and that artifact could potentially shade the javax.inject references. A naive shade would produce some awkward APIs, where Binder (for example) would have toProvider(Class<? extends shaded.javax.inject.Provider) API. (The toProvider methods in Binder are also a problem in general for supporting jakarta.inject, so maybe there's another solution that could deal with those too.) — Reply to this email directly, view it on GitHub <#1383 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABYUQWSTSWXKEGYKE6O4YTXC7O23ANCNFSM4QGL6RWQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

If I were able to cajole folks into a new release of javax.inject (at the javax.inject maven coordinates) that included a module name, etc.. would that make these problems go away?

chore(dependency): upgrade spring boot from 2.7.x to 3.0.x and spring…

refactor(dependency): replace javax.inject with jakarta.inject and up…

chore(dependency): upgrade spring boot from 2.7.x to 3.0.x and spring…

refactor(dependency): replace javax.inject with jakarta.inject and up…

chore(dependency): upgrade spring boot from 2.7.x to 3.0.x and spring…

refactor(dependency): replace javax.inject with jakarta.inject and up…

chore(dependency): upgrade spring boot from 2.7.x to 3.0.x and spring…

Navigation Menu

Repository navigation

jakarta.inject support #1383

105 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

jakarta.inject support #1383

Description

Activity

tandr commented on Mar 9, 2021

GedMarc commented on Mar 10, 2021

kashike commented on May 24, 2021

d135-1r43 commented on Jun 1, 2021

onacit commented on Feb 9, 2022

Azimuts commented on Oct 14, 2022

trintaaho commented on Dec 19, 2022

csisy commented on Mar 17, 2023

xvik commented on Apr 13, 2023

sameb commented on Apr 21, 2023

sameb commented on Apr 25, 2023

norrisjeremy commented on Apr 25, 2023

sameb commented on Apr 25, 2023

martin-g commented on Apr 25, 2023

sameb commented on Apr 25, 2023

105 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions