jakarta.inject support #1383
Comments
|
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. |
|
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. |
|
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:
How much of an issue is this for folks? My plan is basically to keep the 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 |
|
@norrisjeremy -- For one, Google has quite literally millions of files referencing One possibility here is to introduce a separate published artifact with a |
|
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? |
|
@hgschmie: Great! Note there's two relevant commits that didn't make it into rc1: 36ff122 & 4cea397. I'll cut a new rc2 for those this week. Re: 7.0 timeline: I'm hoping in the next few days. I'm almost finished (I hope) on the necessary transformations to rewrite javax->jakarta (or strip where redundant) while pushing from our internal repo to github. |
|
The first thing to thank for the change and the continuity of guice!
I have made the change to guice version 6.0.0-rc1. Along with the main
library I have included guice-persist and guice-servlet (6.0.0-rc1)
I have observed the following problem that did not occur in version 5.1.0
with guice-persist when managing an entity manager :
---------------------------------------------------------------------------------------------------------------------------------
1) [Guice/ErrorInCustomProvider]: IllegalStateException: Requested
EntityManager outside work unit. Try calling UnitOfWork.begin() first, or
use a PersistFilter if you are inside a servlet environment.
while locating JpaPersistService
while locating EntityManager
======================
Full classname legend:
======================
EntityManager: "javax.persistence.EntityManager"
JpaPersistService: "com.google.inject.persist.jpa.JpaPersistService"
-------------------------------------------------------------------------------------------------------------------
I don't know if it's due to some change or something that was latently
wrong....
Thank you.
…On Tue, May 2, 2023 at 10:52 PM Sam Berlin ***@***.***> wrote:
@hgschmie <https://github.com/hgschmie>: Great! Note there's two relevant
commits that didn't make it into rc1: 36ff122
<36ff122>
& 4cea397
<4cea397>.
I'll cut a new rc2 for those this week.
Re: 7.0 timeline: I'm hoping in the next few days. I'm almost finished (I
hope) on the necessary transformations to rewrite javax->jakarta (or strip
where redundant) while pushing from our internal repo to github.
—
Reply to this email directly, view it on GitHub
<#1383 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKAUYVPOLEXS5BKJB5ZBFNTXEFX2RANCNFSM4QGL6RWQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Iker Olabarria OZaeta
|
… replace the rest with their jakarta variants. This required upgrading some test dependencies, because the tests need some impls of the APIs which only exist in newer releases. This also removes the struts2 extension from the maven & bazel build (although it keeps the now-unused source), because struts2 has no release that supports jakarta. For users that want to continue using the struts2 extension, please continue to use the Guice 6.0 release (instead of the 7.0+ line, which will only support the jakarta dependencies). Fixes #1383. (I'll cut the 6.0 candidates/releases from before this commit, and if we need to make further 6.0 changes, I'll manually merge those into the 6.0 branch.) PiperOrigin-RevId: 528636271
|
FYI: #1726 will resolve this, after which I'll cut new RCs, and then shortly after that the actual releases. I need to resolve a few issues with the PR, but it otherwise appears to work as expected. Note: I am NOT updating the javax.annotation.Nullable references, because those don't seem necessary to change. I am updating javax.{inject,servlet,persistence}, though. |
I believe this type has the split package problem which makes it frowned upon due to the Java module system. That's not very common, but was expected to be a decade long transition for adoption anyway. You might consider using the annotation name instead of type like static analyzers have switched to. |
|
@ben-manes: Guice's usage of javax.annotation.Nullable is solely just to annotate methods/params as themselves accepting or returning null values, for code documentation. For checking to see if an injected param can be null, we allow anything named "Nullable". |
… replace the rest with their jakarta variants. This required upgrading some test dependencies, because the tests need some impls of the APIs which only exist in newer releases. This also removes the struts2 extension from the maven & bazel build (although it keeps the now-unused source), because struts2 has no release that supports jakarta. For users that want to continue using the struts2 extension, please continue to use the Guice 6.0 release (instead of the 7.0+ line, which will only support the jakarta dependencies). Fixes #1383. (I'll cut the 6.0 candidates/releases from before this commit, and if we need to make further 6.0 changes, I'll manually merge those into the 6.0 branch.) PiperOrigin-RevId: 528636271
|
Oh great. I believe that is still not module safe, unfortunately. Guava migrated to the checker framework for a time, though I think regressed as they work towards jspecify. But this can probably be ignored as jspecify matures and should replace the usages, and module adoption is still fairly low to not be a blocker. |
|
Hi everyone. I've pushed a 7.0.0-rc1 and a 6.0.0-rc2. The 7.0 is jakarta only, and the 6.0 is javax+jakarta (to the extent that supporting jakarta w/ javax is possible). (Note that it may take a couple hours before the releases are mirrored into maven central.) Please try them out and let me know how they work for you. I would like to cut proper releases soon, but I need feedback from folks that they work as expected. (I'll write proper release notes pages for both 6.0 & 7.0 tomorrow, as well as email the user list about the RCs.) |
|
Thanks for giving it a spin, @cdietrich, and glad to hear the regression was just a mistaken javax import. All: I posted release notes & made a proper announcement post @ #1732. Please follow up there with your success or failure stories in adopting Guice 6.0 or 7.0. Thank you! |
|
6.0.0-rc2 works with the Play Framework and we do have quite some testing going on. I didn't change anything besides bumping the guice version (keep using javax.inject):
7.0.0-rc1 works as well also, switched everything to the jakarta namespace: playframework/playframework#11792 |
|
We will be shipping support for both javax.inject (guice 5.x-6.x) and jakarta.inject (guice 7.x) in the next release of https://github.com/jdbi/jdbi. Testing looks good; ideally we could use the releases as base lines; everything works so far with the release candidates. |
|
RestEasy dropped support for Guice when they migrated to Jakarta. That used to be the more popular JAX-RS framework to use with Guice since Jersey 2 had buggy integration due lifecycle clashes with HK2. I'm hoping they'll restore this module (RESTEASY-3329). |
|
@ben-manes they also dropped any future support for any modules in their entirety - by separating out the spi's, Rest Easy is not compatible with modular development, Guice is a modular DI. |
|
Thanks all, this is great to hear that things are working in your environments. If it's possible to continue the discussion on the release announcement @ #1732, it's a little easier to keep track of the one discussion post instead of comments inside a closed issue. |
Guice 6.x release is adding support for jakarta.inject, see this issue for more details: [1]. Guice release 7.0.0 will remove support for javax.inject annotation and only support jakarta.inject. Also add new dependency to jakarta.inject library. [1] google/guice#1383 Release-Notes: Update guice version to 6.0.0 Change-Id: I0eb5320289bde532ac57bdd376802b37c1cee47f
…f spring boot 3.x upgrade
While upgrading the spring boot to 3.0.13 and spring cloud 2022.0.5, encountered the below error:
```
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'javax.inject.Provider<com.netflix.spectator.api.Registry>' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
at app//org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound(DefaultListableBeanFactory.java:1824)
at app//org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1383)
at app//org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1337)
at app//org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:910)
at app//org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:788)
... 175 more
```
The root cause is use of `javax.inject` that has been moved from present coordinate to `jakarta.inject`. So, updating the coordinates in kork-eureka, kork-plugins and kork-web modules.
google/guice#1463
google/guice#1383
https://docs.openrewrite.org/recipes/java/migrate/jakarta/javaxinjectmigrationtojakartainject
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.
The text was updated successfully, but these errors were encountered: