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
(This is a slightly modified version of @kashike's original PR @ #1715, expanding tests for MapBinder & adding support for OptionalBinder.)
Fixes#1715
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/guice/pull/1715 from kashike:fix/jakarta-multibinder 5d7226eaca
PiperOrigin-RevId: 528762998
As suggested (and I assume also intended) in https://github.com/google/guice/pull/1173 this PR changes the configuration of the maven-bundle-plugin to completely remove the import of the package `javax.annotation`, which seems not to be required at runtime.
With PR https://github.com/google/guice/pull/1173 respectively https://github.com/google/guice/pull/1697 the OSGi package import of `javax.annotation;version="[3.0,4)"` was only changed to `javax.annotation`, i.e. the version range was removed.
Additionally update to latest maven-bundle-plugin 5.1.8.
Fixes#1708
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/guice/pull/1708 from HannesWell:removeJavaxAnnotation 968f4bcd71
PiperOrigin-RevId: 527092811
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
Sam Berlin