* 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
Annotations with retention policy are ignored if they cannot be loaded at runtime (at least according to [Stack-Overvflow](https://stackoverflow.com/questions/3567413/why-doesnt-a-missing-annotation-cause-a-classnotfoundexception-at-runtime)). Make the dependency optional to not enforce the presence of error_prone_annotations in a java runtime even if those annotations are not used at all.
This is especially useful for OSGi-runtimes where you cannot exclude error_prone_annotations because the corresponding package is specified as mandatory requirement in the MANIFEST.MF. Marking the Maven dependency as optional will also result in the error-prone package requirement being marked as optional.
At the moment error_prone_annotations does not come with a OSGi compliant Manifest, which makes it harder to include it in OSGi applications like Eclipse.
I already created a PR at error-prone to include the required OSGi headers (see https://github.com/google/error-prone/pull/3903), but not requiring the annotations at all would make it even simpler to use guice within OSGi.
Alternatively the dependency could be marked as optional in the OSGi metadata.
Fixes#1739
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/guice/pull/1739 from HannesWell:optionalErrorproneAnnotations 86f9de0e50
PiperOrigin-RevId: 531531783
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
(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
