* Bump minimum JRE to 11 (from 8).
* Change testing matrix from {8,11,15,17} to {11,17,21-ea}. (Except the bazel build has trouble parsing "21-ea" as a java version, so s/21-ea/20 for bazel.)
* Also test on macos (but only with jdk17). (Attempted to test on windows too, but there's issues right now.)
* Cleanup the POMs a little bit (remove unused mailing list reference, fix CI link)
* Bump bazel version to 6.2.0, otherwise the tests fail b/c they try to set a security manager (see https://github.com/bazelbuild/bazel/issues/14502, which was fixed in https://github.com/bazelbuild/bazel/commit/7556e1107b666d10b660470a571631463c7eb4ec, which was cherrypicked into the 6.2.0 release). This also required suppressing the "BanJNDI" errorprone check in the JNDI extension, which was also added to 6.2.0. (A future change should probably just remove the JNDI extension altogether.)
PiperOrigin-RevId: 532849632
The error will now generate suggestions only when the message is used (as opposed to on instantiation). This should significantly improve the performance of any code that happens to call `injector.get{Instance,Provider,Binding}` and catches/ignores a `ProvisionException` (with the intention of falling back to code that deals with the type not being bound). While this isn't a great pattern for code to use, and there are far better ways of doing it... there's enough code that does this that it's worthwhile improving.
This pattern in particular was very problematic with the introduction of the jakarta.inject.Provider variants for Multibinders/MapBinders & OptionalBinders, because we have *lots* of those. By adding N more bindings to each multi/map/optionalbinder, we added a very large number of bindings to the overall total, which resulted in code using this pattern getting much slower.
This code also fixes suggestions to skip "UntargettedBindings", which are bindings like `bind(SomeInterface.class)` and aren't a valid suggestion (because they're missing a .to(..)). By standardizing, this otherwise broke a test in BinderTest that was asserting we failed those with proper error messages (showing their source). We would have otherwise started showing their source twice, once in a "Did you mean?" section and again in the normal "bound here" section. But really we shouldn't show these in "Did you mean?" at all, because it's just a repetition (or incorrect suggestion) of the wrong binding.
PiperOrigin-RevId: 531062151
* Bumps the snapshot version to 7.0.1-SNAPSHOT
* Adds Guice 6 & Guice 7 release pages, with explanations of the jakarta transition & how Guice 6.0 & 7.0 should be used. They also include changelogs since 5.1.0.
* Updates the top-level README to reference the 6.0 & 7.0 releases, as well as including "installation instructions" (which fixes#1698).
* Updates the wiki to make sure it's meaningful for both javax & jakarta references, pointing to the correct ones where appropriate.
PiperOrigin-RevId: 529770936
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: 529504991
Calling getObject through reflection breaks Azul JVMs, because the staticFieldBase is a funny "not object", but when passed through reflection it tries to become an Object and fails.
Retrieval of the unsafe is based on how other google open source projects do it, see for example AbstractFuture, UnsignedBytes, and protobufs.
Fixes#1719, and properly fixes#1672.
(Note that this change also bumps the Github Action's bazel version from 4.2.2 to 6.1.2, because somewhere along the way from 4.2.2->6.1.2, Bazel fixed the --javacopts="--release 8" option to also allow sun.misc.Unsafe.)
PiperOrigin-RevId: 529486761
* BoundFieldModule: just say "Provider" and "Qualifier" instead of FQN of each.
* MapBinderTest/MultibinderTest/SpiUtils/ProvidersTest/googlecode.guice.BUILD: reorder some things so it's easier to strip the javax variants
* OptionalBinderTest: introduce a helper that the tests delegate to, so the strip directives can be consolidated
* ContinuingRequestIntegrationTest/ServletTest: Don't pass null for the response in tests that made that fail, pass mocks instead. Earlier HttpServlet impls allowed null, later HttpServlet impls don't allow null.
* ElementsTest: rename javax-referencing to "spec" so it makes sense when its transformed.
* InjectorSpiTest: Run the formatter, since the next CL would have changed this.
* BoundFieldModuleTest: Reference javax explicitly in some places, explicitly don't reference it in others.
* OSGiContainerTest: Add a TODO about the test's uselessness
* pom.xml: Enable maven test failures to include stack traces, so we have some idea WTF went wrong when things go wrong.
PiperOrigin-RevId: 529463507
Much thanks goes to @nineninesevenfour for their investigation (in #1650), which made fixing this much easier.
Fixes#700 and fixes#1650.
PiperOrigin-RevId: 527048972
(Also changes the classname suffix to be a hex string instead of an int, which had previously included a leading negative sign, which was weird.)
Fixes#1340 & fixes#187.
PiperOrigin-RevId: 526291523
Notably, this does *not* change things to allow scoping annotations on interfaces or abstract classes (even though theoretically we could, because the @ProvidedBy will be instantiating it). Scopes on abstract classes|interfaces will still throw an exception about the scope being misplaced.
Fixes#251 and fixes#1319.
PiperOrigin-RevId: 526009187
(This does not use the suggested code from the original PR, and does not attempt to change the `testManyMethods` method because we assume that repeated calls to `getDeclaredMethods` will always return the same order of methods. If that ever changes, we can deal with it then.)
PiperOrigin-RevId: 525220025
We now only remove the guard if we aren't in the process of loading that JIT binding. The failed JIT binding is naturally cleaned up later on, as the existing & new tests attest to.
Fixes many issues:
- Fixes#1633
- Fixes#785
- Fixes#1389
- Fixes#1394
Many thanks to @swankjesse for the test-case added in #1389 that was helpful in diagnosing the problem, and to @PaulFridrick for the diagnoses in #1633.
PiperOrigin-RevId: 525219839
* T1: Enter `lockOrDetectPotentialLocksCycle`:
- Lock CAF.class, add itself to `lockThreadIsWaitingOn`, unlock CAF.class
- Lock the cycle detecting lock (CDL)
- Lock CAF.class, mark itself as `lockOwnerThread`, remove itself from `lockThreadIsWaitingOn`
- Exit `lockOrDetectPotentialLocksCycle`
* T1: Re-enter `lockOrDetectPotentialLocksCycle`:
- Lock CAF.class, add itself to `lockThreadIsWaitingOn`, unlock CAF.class
T2: Enter `lockOrDetectPotentialLocksCycle`
- Lock CAF.class, invoke `detectPotentialLocksCycle`.
At this point, `detectPotentialLocksCycle` will now loop forever, because the `lockOwnerThread` is also in `lockThreadIsWaitingOn`. During the course of looping forever, it will OOM, because it's building up an in-memory structure of what it thinks are cycles.
The solution is to avoid the re-entrant T1 from adding itself to `lockThreadIsWaitingOn` if it's already the `lockOwnerThread`. It's guaranteed that it won't relinquish the lock concurrently, because it's the exact same thread that owns it.
Fixes#1635 and Fixes#1510
PiperOrigin-RevId: 525182219
This change will log a single failure when Guice encounters an exception while reading classfiles and warn that ASM may be out of date.
The consequences of this failing _all_ line number reading (due to, say, an accidental bug introduced while parsing classfiles) is that Guice won't emit line numbers for bind statements in modules (as binding source locations). A number of other tests would fail in that scenario, warning us that something is off.
PiperOrigin-RevId: 524387180
Rewrite the way we iterate through method handle lookups. Don't cache fallback behavior. Instead, eagerly discover what the JDK supports & cache that. On use, if it fails (likely because a proper lookups wasn't supplied), then fallback (but do not cache the fallback).
All these shenanigans are only necessary if javac generated a default method that Guice needs to invoke. Because AssistedInject uses a JDK Proxy, which also proxies default interface methods, we need to use invokespecial to target the proxy (otherwise proxying the method will end up with a stack overflow due to infinite recursion). Note that if we implemented this by code generation, we wouldn't need these hacks... so we take some pains to allow non-public factories without *requiring* the user to call withLookups(..). But the workarounds don't always work, so we still need the withLookups(..) method.
PiperOrigin-RevId: 423822309
Automated rollback of changelist 32fef20b16
*** Original change description ***
Automated rollback of commit 37255a24d9
*** Original change description ***
Refactor code to use java8-isms.
Generated with refaster, with some manual touch-ups afterwards.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=238487042
*** Original change description ***
Refactor code to use java8-isms.
Generated with refaster, with some manual touch-ups afterwards.
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=238342841
Generated with refaster, with some manual touch-ups afterwards.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=238042288
Update Injectors to keep track of ProviderLookups attached to InjectionPoints, since these are meaningful for SPI usages.
(See the linked bug for the rationale of why we're adding this.)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=230719723
Also remove the jdk10 build from Travis because it doesn't support it anymore and we don't really need it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219129959
The only sane fix I can think of here is to just blanket ignore unsupported things when parsing line numbers, because even if your code is compiled for an earlier target (all of Guice's code+tests are compiled to target JDK 1.7), the JDK itself might be higher, and code may trigger Guice to try to do ASM operations against the JDK.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213313384
This converts the BindingProto to use oneofs instead of a type enum in order to let it grow more easily for extensions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=194102075
Sam Berlin