PiperOrigin-RevId: 503916049

PiperOrigin-RevId: 505840946

PiperOrigin-RevId: 516590803

…cates() is specified.

PiperOrigin-RevId: 517978849

Fixes #1671
Fixes #1657
Fixes #1654
Fixes #1521
Fixes #1256

PiperOrigin-RevId: 524365072

Fixes #1656
Fixes #1655

PiperOrigin-RevId: 524374664

…sses with ASM, so Guice is less finicky about the precise .class version & ASM version. A while ago I had tried to do this by ignoring UnsupportedOperationException, but per #1654, ASM doesn't always throw UOE.

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

…e know that's where the field is declared.

Fixes #1673
Fixes #1672

PiperOrigin-RevId: 524835342

…would previously fail:

 * 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

PiperOrigin-RevId: 525219514

… with the new version. Fixes #1624.

PiperOrigin-RevId: 525219685

PiperOrigin-RevId: 525219738

…nd/or crash inside Guava's LoadingCache. The problem had to do with the fact that Guice eagerly stores uninitialized JIT bindings in an attempt to allow circular dependencies, and Guice also attempts to cleanup failed JIT bindings (to remove these uninitialized JIT bindings). The JIT binding cache was a guard against a recursive call back into the constructor's cache, but we were removing that guard.

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

… returned in any order from Method.getGenericExceptionTypes. Fixes #1603.

(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

…n subclasses. Fixes #1569 & fixes #1525. (The primary use-case for this is to override binder() to always call skipSources, like many AbstractModule impls.)

PiperOrigin-RevId: 525231256

…ossible. Fixes #1556

PiperOrigin-RevId: 525231598

…date the version we use.

PiperOrigin-RevId: 525459640

…the importance of otherwise unnecessary binding statements.

Closes #973, a documentation alternative to #1337.

PiperOrigin-RevId: 525497931

… matches its javadoc. Fixes #1214, fixes #972, fixes #598.

PiperOrigin-RevId: 525556346

…e system line separator and always using \n explicitly. (We were previously inconsistent: many places used \n, and many other places used %n with a formatter, which would end up being the system line separator.) This allows tests to pass on Windows, where the line separator is different. Also update tests to do a run with the windows line separator, to catch regressions. Fixes #1213.

PiperOrigin-RevId: 525558598

PiperOrigin-RevId: 525564484

…Fixes #1171.

PiperOrigin-RevId: 525564737

…ou only need it if you want to perform null analysis on the code). Fixes #1172

PiperOrigin-RevId: 525741584

PiperOrigin-RevId: 525805514

PiperOrigin-RevId: 525815800

PiperOrigin-RevId: 525828170

 #1071.

PiperOrigin-RevId: 525898592

…ProvidedBy when using the @ProvidedBy as the provider.

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

 #788.

PiperOrigin-RevId: 526087773

…because it leads to leaks. Fixes #739, fixes #997, fixes #730, fixes #985, fixes #959, fixes #731. This also adds an optional Options to the JpaPersistModule constructor, if users wish to use the legacy behavior. This is a breaking change, but to a better default value. Users who want to keep the dangerous form can opt back in with the options.

PiperOrigin-RevId: 526106112

… Much thanks to @kenwenzel and @mcculls for their help figuring out the right incantation for this.

PiperOrigin-RevId: 526290216

…eturning the unenhanced version).

(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

…tedBy. Instead, defer it like a normal bind(X.class).to(Y.class) does. This ensures that later bindings of Y are used.

Much thanks goes to @nineninesevenfour for their investigation (in #1650), which made fixing this much easier.

Fixes #700 and fixes #1650.

PiperOrigin-RevId: 527048972

As suggested (and I assume also intended) in #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 #1173 respectively #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=#1708 from HannesWell:removeJavaxAnnotation 968f4bc
PiperOrigin-RevId: 527092811

This does not add support for `toProvider(...)` to instances of `jakarta.inject.Provider` or classes/keys/typeLiterals of type `jakarta.inject.Provider`. See #1383 (comment) for details of the plans. The Guice 6.0 release will support `javax.inject` _and_ `jakarta.inject` (excluding `toProvider()` support for `jakarta.inject`), and the Guice 7.0+ release will remove the `javax.inject` references.

Further background on these issues:
 * #1630
 * #1679
 * #1490
 * #1383

PiperOrigin-RevId: 527349023

PiperOrigin-RevId: 527647564

PiperOrigin-RevId: 527669293

PiperOrigin-RevId: 528546653

Fixes #1716
Fixes #1177

COPYBARA_INTEGRATE_REVIEW=#1716 from kashike:feature/and-or-matchers d1d6322
PiperOrigin-RevId: 528558457

…ilding new binders by calling skipSources on-demand, we just skip all the expected sources by default. This significantly reduces some memory pressure when creating injectors (which was otherwise causing issues with the forthcoming CL to additionally bind jakarta Provider variants for MapBinder/Multibinder/OptionalBinder).

PiperOrigin-RevId: 528758521

…der, MapBinder & OptionalBinder.

(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=#1715 from kashike:fix/jakarta-multibinder 5d7226e
PiperOrigin-RevId: 528762998

…ethodScanner scopes and BytecodeGenTest.

PiperOrigin-RevId: 528900279

…at strip javax and only use the jakarta variants.

* 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

… unit if work is started, to help users transition to the new default that requires an explicit work open (or the legacy option set).

PiperOrigin-RevId: 529465168

…nsafe, and call getObject on it natively instead of through reflection.

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](https://github.com/google/guava/blob/d4bd0c5ffa913104283e61aeb2c41bac641af042/guava/src/com/google/common/util/concurrent/AbstractFuture.java#L1340-L1365), [UnsignedBytes](https://github.com/google/guava/blob/6405852bbf453b14d097b8ec3bcae494334b357d/guava/src/com/google/common/primitives/UnsignedBytes.java#L341-L366), and [protobufs](https://github.com/protocolbuffers/protobuf/blob/520c601c99012101c816b6ccc89e8d6fc28fdbb8/java/core/src/main/java/com/google/protobuf/UnsafeUtil.java#L289-L315).

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: 529465570

…is validating that the parent can't re-bind something from the private module. If nothing is exposed, the child/private injector can otherwise be immediately GC'd (which then allows the parent to have the binding). (Note that there are other ways the child/private module could be captured: such as a Provider or its Injector being captured into a longer-lived Thread... but this is the simplest way to do it). This is happening with some regularity on the Github Actions tests, making the tests a bit flaky.

PiperOrigin-RevId: 529467328

PiperOrigin-RevId: 529476888

…nsafe, and call getObject on it natively instead of through reflection. (Take 2, after exempting its usages internally.)

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

… 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: 529504991

…ing:

* 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

…esn't get transformed into jakarta.

Also note that 5.1 only supports javax.

PiperOrigin-RevId: 529858655

… necessary because we share the internal factory implementation, which leads to initialize(..) being called multiple times. There are other consequences/quirks of this, but re-initialization is the worst of it.

PiperOrigin-RevId: 530339379

PiperOrigin-RevId: 530658894

… instead of linking to the same internal factory implementation. (Reusing the internal factory results in some quirks that we want to avoid.)

PiperOrigin-RevId: 530977598

…d standardize its output.

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

PiperOrigin-RevId: 531069248

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 google/error-prone#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=#1739 from HannesWell:optionalErrorproneAnnotations 86f9de0
PiperOrigin-RevId: 531531783

…7.0.0 as the last releases, update the 6.0.0 & 7.0.0 release pages.

PiperOrigin-RevId: 531554646

* 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 bazelbuild/bazel#14502, which was fixed in bazelbuild/bazel@7556e11, 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

PiperOrigin-RevId: 538300298

Bumps [guava](https://github.com/google/guava) from 31.0.1-jre to 32.0.0-jre.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/google/guava/releases">guava's releases</a>.</em></p>
<blockquote>
<h2>32.0.0</h2>
<h3>Maven</h3>
<pre lang="xml"><code>&lt;dependency&gt;
  &lt;groupId&gt;com.google.guava&lt;/groupId&gt;
  &lt;artifactId&gt;guava&lt;/artifactId&gt;
  &lt;version&gt;32.0.0-jre&lt;/version&gt;
  &lt;!-- or, for Android: --&gt;
  &lt;version&gt;32.0.0-android&lt;/version&gt;
&lt;/dependency&gt;
</code></pre>
<h3>Jar files</h3>
<ul>
<li><a href="https://repo1.maven.org/maven2/com/google/guava/guava/32.0.0-jre/guava-32.0.0-jre.jar">32.0.0-jre.jar</a></li>
<li><a href="https://repo1.maven.org/maven2/com/google/guava/guava/32.0.0-android/guava-32.0.0-android.jar">32.0.0-android.jar</a></li>
</ul>
<p>Guava requires <a href="https://github.com/google/guava/wiki/UseGuavaInYourBuild#what-about-guavas-own-dependencies">one runtime dependency</a>, which you can download here:</p>
<ul>
<li><a href="https://repo1.maven.org/maven2/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar">failureaccess-1.0.1.jar</a></li>
</ul>
<h3>Javadoc</h3>
<ul>
<li><a href="http://guava.dev/releases/32.0.0-jre/api/docs/">32.0.0-jre</a></li>
<li><a href="http://guava.dev/releases/32.0.0-android/api/docs/">32.0.0-android</a></li>
</ul>
<h3>JDiff</h3>
<ul>
<li><a href="http://guava.dev/releases/32.0.0-jre/api/diffs/">32.0.0-jre vs. 31.1-jre</a></li>
<li><a href="http://guava.dev/releases/32.0.0-android/api/diffs/">32.0.0-android vs. 31.1-android</a></li>
<li><a href="http://guava.dev/releases/32.0.0-android/api/androiddiffs/">32.0.0-android vs. 32.0.0-jre</a></li>
</ul>
<h3>Changelog</h3>
<h4>Security fixes</h4>
<ul>
<li>Reimplemented <code>Files.createTempDir</code> and <code>FileBackedOutputStream</code> to further address CVE-2020-8908 (<a href="https://redirect.github.com/google/guava/issues/4011">#4011</a>) and CVE-2023-2976 (<a href="https://redirect.github.com/google/guava/issues/2575">#2575</a>). (feb83a1c8f)</li>
</ul>
<p>While CVE-2020-8908 was officially closed when we deprecated <code>Files.createTempDir</code> in <a href="https://github.com/google/guava/releases/tag/v30.0">Guava 30.0</a>, we've heard from users that even recent versions of Guava have been listed as vulnerable in <em>other</em> databases of security vulnerabilities. In response, we've reimplemented the method (and the very rarely used <code>FileBackedOutputStream</code> class, which had a similar issue) to eliminate the insecure behavior entirely. This change could technically affect users in a number of different ways (discussed under &quot;Incompatible changes&quot; below), but in practice, the only problem users are likely to encounter is with Windows. If you are using those APIs under Windows, you should skip 32.0.0 and go straight to <a href="https://github.com/google/guava/releases/tag/v32.0.1">32.0.1</a> which fixes the problem. (Unfortunately, we didn't think of the Windows problem until after the release. And while we <a href="https://github.com/google/guava#important-warnings">warn that <code>common.io</code> in particular may not work under Windows</a>, we didn't intend to regress support.) Sorry for the trouble.</p>
<h4>Incompatible changes</h4>
<p>Although this release bumps Guava's major version number, it makes <strong>no binary-incompatible changes to the <code>guava</code> artifact</strong>.</p>
<p>One change could cause issues for Widows users, and a few other changes could cause issues for users in more usual situations:</p>
<ul>
<li><strong>The new implementations of <code>Files.createTempDir</code> and <code>FileBackedOutputStream</code> <a href="https://redirect.github.com/google/guava/issues/6535">throw an exception under Windows</a>.</strong> This is fixed in <a href="https://github.com/google/guava/releases/tag/v32.0.1">32.0.1</a>. Sorry for the trouble.</li>
<li>This release makes a binary-incompatible change to a <code>@beta</code> API in the <strong>separate artifact</strong> <code>guava-testlib</code>. Specifically, we changed the return type of <code>TestingExecutors.sameThreadScheduledExecutor</code> to <code>ListeningScheduledExecutorService</code>. The old return type was a package-private class, which caused the Kotlin compiler to produce warnings. (dafaa3e435)</li>
<li>This release <em>adds</em> two methods to the Android flavor of Guava: <code>Invokable.getAnnotatedReturnType()</code> and <code>Parameter.getAnnotatedType()</code>. Those methods do not work under an Android VM; we added them only to help our tests of the Android flavor (since we also run those tests under a JRE). Android VMs tolerate such methods as long as the app does not call them or perform reflection on them, and builds tolerate them because of our new Proguard configurations (discussed below). Thus, we expect no impact to most users. However, we could imagine build problems for users who have set up their own build system for the Android flavor of Guava. Please report any problems so that we can judge how safely we might be able to add other methods to the Android flavor in the future, such as APIs that use Java 8 classes like <code>Stream</code>. (b30e73cfa81ad15c1023c17cfd083255a3df0105)</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a href="https://github.com/google/guava/commits">compare view</a></li>
</ul>
</details>
<br />

[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=com.google.guava:guava&package-manager=maven&previous-version=31.0.1-jre&new-version=32.0.0-jre)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/google/guice/network/alerts).

</details>

Fixes #1750

COPYBARA_INTEGRATE_REVIEW=#1750 from google:dependabot/maven/com.google.guava-guava-32.0.0-jre 0b37845
PiperOrigin-RevId: 541918122

Bumps [struts2-core](https://github.com/apache/struts) from 2.5.30 to 2.5.31.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/apache/struts/releases">struts2-core's releases</a>.</em></p>
<blockquote>
<h2>Struts 2.5.31</h2>
<h2>What's Changed</h2>
<ul>
<li><a href="https://github.com/apache/struts/commit/2d6f1bc0a6f5ac575a56784ac6461816b67c4f21">Fixes</a> addressing <a href="https://cwiki.apache.org/confluence/display/WW/S2-063">S2-063</a> &amp; <a href="https://cwiki.apache.org/confluence/display/WW/S2-064">S2-064</a> by <a href="https://github.com/yasserzamani"><code>@​yasserzamani</code></a></li>
</ul>
<p><strong>Full Changelog</strong>: <a href="https://github.com/apache/struts/compare/STRUTS_2_5_30...STRUTS_2_5_31">https://github.com/apache/struts/compare/STRUTS_2_5_30...STRUTS_2_5_31</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a href="https://github.com/apache/struts/commits">compare view</a></li>
</ul>
</details>
<br />

[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=org.apache.struts:struts2-core&package-manager=maven&previous-version=2.5.30&new-version=2.5.31)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/google/guice/network/alerts).

</details>

Fixes #1749

COPYBARA_INTEGRATE_REVIEW=#1749 from google:dependabot/maven/extensions/struts2/org.apache.struts-struts2-core-2.5.31 e9b9dde
PiperOrigin-RevId: 541919125

`Module` is implicitly a `@FunctionalInterface` already. That is very convenient, as it allows to express

```
methodThatTakesAModule(
    new AbstractModule(){
      @OverRide
      protected void configure() {
        bind(Foo.class).annotatedWith(Bar.class).toInstance(barredFoo);
      }
    }
);
```

as

```
methodThatTakesAModule(binder -> binder.bind(Foo.class).annotatedWith(Bar.class).toInstance(barredFoo));
```

PiperOrigin-RevId: 544058444

PiperOrigin-RevId: 547836342

PiperOrigin-RevId: 555492476

…s not EA.

PiperOrigin-RevId: 571115942

PiperOrigin-RevId: 571969961

PiperOrigin-RevId: 573252178

PiperOrigin-RevId: 576885259

PiperOrigin-RevId: 577308018

PiperOrigin-RevId: 578306054

PiperOrigin-RevId: 578574921

PiperOrigin-RevId: 581989087

…referenced libs that aren't published anymore.

PiperOrigin-RevId: 597242944

…tedSize, and avoid an extra T[] array allocation when permitDuplicates==true.

Since the normal usage should be that the items in the values array are all unique, and ImmutableSet#copyOf will create an initial list of max(4, sqrt(length)) if length>4, but then grows that list to length (or larger) if the array was all unique (and then resize is back down during build()).

While here, the T[] values array is also only needed to be filled in when permitDuplicates==false (for the error message if duplicates were detected).

PiperOrigin-RevId: 597244931

New commit: google/bazel-common@2a6b640

This helps with google/truth#746.

PiperOrigin-RevId: 602832261

…ruth.assertThat`, and qualify others.

By "qualify," I mean that, instead of static importing `Truth8.assertThat`, we write "`Truth8.assertThat(...)`" at the call site.

This is normally the opposite of what we recommend. However, it's a necessary step in our migration: We are copying all the `Truth8` methods to `Truth`, and we can't do that if any files static import both `Truth.assertThat` and `Truth8.assertThat` (because it produces a compile error about ambiguous overloads). To unblock that, we're moving callers away from the static import.

We will update static analysis to stop suggesting the import.

A later step will migrate these callers to the new `Truth.assertThat` methods, which we will static import.

The `Truth8` methods will be hidden in the future. All callers will use `Truth`.

PiperOrigin-RevId: 603073706

…v1.4.0).

This makes available the rest of the Truth APIs that were recently added in Google's monorepo.

It may be worth also updating to the _following_ version of Truth after it's released, but the purpose of that release will mostly be to deprecate `Truth8`. So, if you just avoid using `Truth8` now (starting by approving any migration CLs that I send your way), then there will be little need for that upgrade. Or, more to the point: I don't expect to keep sending you weekly upgrade CLs after this one :)

PiperOrigin-RevId: 604719853

…assertThat`.

The `Truth8` methods will be deprecated (or hidden) in the future. Callers should move to `Truth`.

Some (but not all) of the CLs in this batch require Truth [1.4.0](https://github.com/google/truth/releases/tag/v1.4.0). I submitted a CL earlier today to (I hope) perform that upgrade for your project.

PiperOrigin-RevId: 604731456

PiperOrigin-RevId: 609175545

PiperOrigin-RevId: 609419903

…his is useful in some cases where the scanner bindings need more information from the module currently being scanned.

PiperOrigin-RevId: 615788414

RELNOTES=n/a
PiperOrigin-RevId: 617628676

PiperOrigin-RevId: 619545649

… base level is JDK11.

PiperOrigin-RevId: 620889085

Loads are being added in preparation for moving the rules out of Bazel and into `rules_java`.

PiperOrigin-RevId: 621873514

Loads are being added in preparation for moving the symbols out of Bazel and into `rules_java`.

PiperOrigin-RevId: 624858712

…it works on the latest macos on github. Also update to the latest Bazel version that supports JavaInfo rule imports, and fix things that break w/ the latest bazel version (requiring imports for defining package statements if a package_info.java exists, and not using `@local_jdk//:jar`).

PiperOrigin-RevId: 631081930

…d can be simplified to just the input parameter.

PiperOrigin-RevId: 631556426

…record the state in a public boolean field. Change UnsafeClassDefiner to check HiddenClassDefiner state and set UNSAFE_DEFINER as null if there's an error. An IllegalStateException is thrown if HiddenClassDefiner.define() is called in that case.

PiperOrigin-RevId: 631862800