chore(deps): bump the maven-version-updates group across 1 directory with 32 updates

[dependabot]

Bumps the maven-version-updates group with 32 updates in the / directory:

Package	From	To
org.bouncycastle:bcprov-jdk18on	1.84	1.86
org.bouncycastle:bcpkix-jdk18on	1.84	1.86
com.google.errorprone:error_prone_core	2.40.0	2.50.0
com.uber.nullaway:nullaway	0.12.7	0.14.1
com.nimbusds:nimbus-jose-jwt	10.4	10.9.1
com.nimbusds:oauth2-oidc-sdk	11.26	11.38.2
org.apache.httpcomponents.client5:httpclient5	5.6.3	5.6.4
com.fasterxml.jackson.core:jackson-core	2.22.1	2.22.2
com.fasterxml.jackson.core:jackson-databind	2.22.1	2.22.2
com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider	2.22.1	2.22.2
com.fasterxml.jackson.datatype:jackson-datatype-jsr310	2.22.1	2.22.2
com.fasterxml.jackson.core:jackson-annotations	2.21	2.22
com.fasterxml.jackson.core:jackson-databind	2.22.1	2.22.2
com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider	2.22.1	2.22.2
com.fasterxml.jackson.datatype:jackson-datatype-jsr310	2.22.1	2.22.2
org.openapitools:jackson-databind-nullable	0.2.6	0.2.11
org.junit.jupiter:junit-jupiter-api	5.13.4	6.1.3
org.testcontainers:testcontainers	1.21.4	2.0.5
io.github.classgraph:classgraph	4.8.181	4.8.195
org.jetbrains.kotlin:kotlin-stdlib	2.1.10	2.4.20
org.apache.commons:commons-compress	1.27.1	1.28.0
com.google.errorprone:error_prone_annotations	2.40.0	2.50.0
org.slf4j:slf4j-simple	2.0.17	2.0.19
com.github.spotbugs:spotbugs-maven-plugin	4.9.3.2	4.10.4.1
org.apache.maven.plugins:maven-compiler-plugin	3.14.0	3.16.0
org.apache.maven.plugins:maven-enforcer-plugin	3.6.1	3.6.3
org.apache.maven.plugins:maven-surefire-plugin	3.5.3	3.6.0
org.apache.maven.plugins:maven-jar-plugin	3.4.2	3.5.1
org.codehaus.mojo:build-helper-maven-plugin	3.6.1	3.6.2
org.apache.maven.plugins:maven-javadoc-plugin	3.11.2	3.12.0
org.apache.maven.plugins:maven-source-plugin	3.3.1	3.4.0
org.jacoco:jacoco-maven-plugin	0.8.13	0.8.15
org.apache.maven.plugins:maven-failsafe-plugin	3.5.3	3.6.0
com.diffplug.spotless:spotless-maven-plugin	2.46.0	3.10.2
org.sonatype.central:central-publishing-maven-plugin	0.8.0	0.11.0

Updates org.bouncycastle:bcprov-jdk18on from 1.84 to 1.86

Changelog

Sourced from org.bouncycastle:bcprov-jdk18on's changelog.

Bouncy Castle Crypto Package - Release Notes

1.0 Introduction

The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms. The package is organised so that it contains a light-weight API suitable for use in any environment (including the J2ME) with the additional infrastructure to conform the algorithms to the JCE framework.

2.0 Release History

2.1.1 Version

Release: 1.87
Date: 2026, TBD

2.1.2 Defects Fixed

• A KeyAgreement asked for its shared secret before doPhase returned data rather than refusing. javax.crypto.KeyAgreement specifies IllegalStateException for that state, but nothing in the provider tracked it, so each SPI handed back whatever its result field held: for Diffie-Hellman that was the private value itself - engineInit seeded result with x, so generateSecret() returned the private exponent padded to the prime's length and generateSecret("AES") an all-zero key taken from that padding - while ECDH returned null and its named-algorithm overload raised NullPointerException. BaseAgreementSpi now records whether a doPhase has completed the agreement since the last init and refuses the request with an IllegalStateException naming the algorithm, so every family in the provider - DH, ECDH and ECMQV, the SM2 exchange, both ECGOST families, XDH, SM9 and NewHope - answers the same way, and the DH SPI no longer holds the private value in that field at all.

• Mac.getInstance and KeyGenerator.getInstance by the HMAC SHA-512/224 and SHA-512/256 object identifiers (1.2.840.113549.2.12 and .13) failed, although the same algorithms resolved by name and the matching SecretKeyFactory aliases were registered: the SHA512 mappings called addHMACAlgorithm for the two truncated variants without the addHMACAlias that registers their OIDs against Mac and KeyGenerator. Both are now aliased, as every other HMAC in that class already was.

• A KTSParameterSpec naming an HKDF key-derivation function with a parameters field - a form the provider does not service - was accepted at Cipher init and then failed out of wrap or unwrap with an unchecked IllegalStateException neither method declares. The KTS key-wrapping Ciphers (ML-KEM, Classic McEliece, FrodoKEM, the composite KEM and RSA-KEM) now validate the spec's KDF when they take it, reporting an unserviceable one as the InvalidAlgorithmParameterException engineInit declares, which is what the javax.crypto.KEM services already did through KdfUtil.resolveKemSpec.

• A DTLS handshake deadlocked when a handshake message ahead of the peer's ChangeCipherSpec (a client's CertificateVerify, say) was lost while the ChangeCipherSpec and Finished behind it arrived: the record layer moved its read epoch on at the ChangeCipherSpec and then discarded every retransmission of the lost message as belonging to the old epoch, whose records are only accepted once the handshake has completed. Each side then waited on the other until a handshake timeout, if one was configured, ended it. Every client-authenticated handshake, and every handshake in which the server issues a NewSessionTicket, was exposed. Until the handshake completes, handshake records from the current epoch are now still accepted after the read epoch has moved on, and each message is checked against the epoch of the record that carried it. The DTLS loopback tests now run their handshakes at 10% datagram loss in each direction, with a client-authenticated handshake at 25%.

• The lightweight SubjectPublicKeyInfoFactory and PrivateKeyInfoFactory encoded a GOST R 34.10-2012 key on one of the legacy CryptoPro curves under id-GostR3410-2001, although RFC 9215 sec. 4.2 permits those curves for 2012 keys. The digestParamSet now decides: a GOST R 34.11-94 parameter set means 2001 (RFC 4491 sec. 2.3.2), a GOST R 34.11-2012 digest or none means 2012 with 256/512 taken from the curve field size, and any other value is rejected. GOST3410PublicKeyAlgParameters treats digestParamSet as OPTIONAL on both read and write per RFC 9215, and PrivateKeyInfoFactory now passes attributes through for ECGOST3410 keys (bc-csharp github #707).

• The name-constraint host canonicalisation removed a single RFC 1034 root-label dot, the only empty label a name may legally carry, but nothing refused the ones that are not legal: a dNSName, rfc822Name host or uniformResourceIdentifier host such as "example.com.." kept a phantom empty label after the strip and so matched no constraint at all, escaping an excluded subtree naming the host it appears to carry. A tested name whose host carries an empty label - a second trailing dot, a doubled dot or a leading dot - is now refused outright wherever a constraint of that type is in force, rather than canonicalised into a name it is not: removing the extra dots would decide on the caller's behalf that "example.com.." names example.com, which is not how a consumer resolving or comparing the name reads it, and refusing fails closed in both directions where canonicalising would newly admit such a name under a permitted subtree. The single trailing dot is canonicalised as before, a bare "." remains the root label rather than an empty one, and the guard is scoped to the host, so the doubled dot a quoted local part may legally carry is unaffected. Constraints are untouched - one may still begin with a dot, which is how this implementation spells "subdomains only" (github PR #2436).

2.1.3 Additional Features and Functionality

2.1.4 Additional Notes

• The sources and javadoc jars of the Ant-built distributions (jdk14, jdk15to18 and jdk13) no longer carry test material. Each module's javadoc target copies the package documentation it needs - org/bouncycastle///*.html - back into the module source directory that has already been compiled from, and zip-src zips that directory afterwards, so every test package's package.html arrived in the sources jar by that route; javadoc-util additionally copied org/bouncycastle/asn1/isismtt//*.java, which put test classes into the bcutil javadoc as generated pages, and javadoc-pg deliberately copied the gpg and bcpg test sources in order to document them. Separately the source copies excluded test material only one directory deep and only for *.java, because Ant reads ** as an any-depth wildcard just where it is a whole path segment, so anything nested further or with another extension - the PEM certificate fixtures under org/bouncycastle/est/test/san corrected in 1.86, and an ICAO master list under org/bouncycastle/asn1/icao/test - went through. The source and javadoc copies of every module now exclude test directories at any depth, and javadoc-pg no longer documents the test packages. org.bouncycastle.util.test is unaffected and still ships in the bcprov binary, sources and javadoc jars, as it does from the Gradle build: it is the SimpleTest framework the light-weight API's own test classes are written against, not test material of the distribution. No binary changes - the classes and resources of every Ant-built jar are identical to those of the 1.86 release - and the Gradle-built jdk18on artifacts never carried any of this.

2.2.1 Version

Release: 1.86
Date: 2026, 11th September.

2.2.2 Defects Fixed

• The high-level OpenPGP API let a subkey inherit the primary key's Key Flags when its own Subkey Binding signature carried none, so a subkey bound with no flags counted as signing-capable for one check while the cross-certification check RFC 9580 sec. 5.2.1.8 requires of a signing subkey saw none and was skipped - letting a third party's public signing subkey be bound to an attacker's primary key and that party's genuine signatures verify under the attacker's identity. Flags are no longer inherited (CVE-2026-71887).
• The high-level OpenPGP API used a version 6 key carrying no valid Direct Key signature, falling back to the primary user ID binding as it correctly does for version 4. RFC 9580 sec. 5.2.3.10 requires the opposite, and since a v6 certificate carries its expiration and preferences there, stripping that one packet silently dropped them - the certificate went on offering subkeys of a key set to expire. isBoundBy now requires a valid Direct Key self-signature before any v6 component is treated as bound; version 4 is unaffected.
• The high-level OpenPGP API ignored the OpenPGPPolicy a caller had configured when verifying signatures on an inline message: OpenPGPMessageInputStream took the policy from the implementation's own default rather than from the processor doing the verification, so a hardened policy had no bearing on acceptance and getSignatures() reported isTestedCorrect() true for a signature that policy rejects. Both the one-pass and prefixed-signature paths now read the configured policy.
• The high-level OpenPGP API went on offering the subkeys of a certificate whose primary key had expired, the binding check evaluating only a subkey's own Subkey Binding signature - so the certificate contradicted itself, reporting the primary unbound while still handing out its subkeys. The primary key's expiration now applies to the whole certificate, as GnuPG and Sequoia treat it, and a subkey no longer inherits the primary's validity period, which RFC 9580 sec. 5.2.3.13 counts from the creation time of the key the carrying signature is made on.
• OpenPGPDocumentSignature.isValidAt(Date) reported a data signature as valid past the signature's own Signature Expiration Time (RFC 9580 sec. 5.2.3.18): it checked that the signature was correct and the issuing key bound and signing-capable at that date, but never the signature's own expiration, so it disagreed with isEffectiveAt() on the same object and with its own javadoc. isValid() and isValid(policy), which evaluate at creation time, are unchanged.
• The lightweight LMSSigner and HSSSigner refused a key wrapped in ParametersWithRandom, which is how BcContentSignerBuilder passes one once setSecureRandom() has been called, so BcHssLmsContentSignerBuilder failed with "Incorrect Key Parameters" and the two signers raised ClassCastException. All three now unwrap it, as the ML-DSA and SLH-DSA signers already did; the random is accepted and ignored, LMS deriving its message randomiser deterministically from the seed and one-time index.
• LMS signature verification did not apply two checks RFC 8554 sec. 5.4.2 requires before a signature is processed: step 2g, refusing a signature whose LMS typecode is not the public key's - without it a signature claiming a height-25 parameter set drove a 25-level computation against a height-5 key - and step 2i, refusing a leaf number outside the tree. Neither was a forgery, but both are attacker-chosen work the specification says to refuse up front. Both are now checked.
• The LMS and HSS key parameter classes now apply at construction the checks their decoders apply, so a key built directly cannot be one the decoder would refuse: LMSPrivateKeyParameters accepted an identifier of any length where the decoder reads exactly 16 bytes, and left q, maxQ and the seed length unchecked, while HSSPrivateKeyParameters checked neither its level count nor that it had a component key and chaining signature per level. The decoders now report a bad version or seed length as IOException rather than IllegalStateException.
• In the LMS JCE layer, LMSKeyGenParameterSpec.fromNames knew all twenty LMS parameter-set names but only four of the sixteen LM-OTS ones, so none of the SP 800-208 n24 or SHAKE sets could be named; all sixteen are now present. initialize(int, SecureRandom) now reports InvalidParameterException as the JCA specifies, and BCLMSPrivateKey.getIndex takes the exhaustion check and the index read under one monitor.
• KeyPairGenerator.initialize(int, SecureRandom) is documented to raise InvalidParameterException when the key size is not one the generator supports, and thirty of them raised a bare IllegalArgumentException instead. Every generator in BCPQC, and the ML-DSA, ML-KEM, SLH-DSA, Classic McEliece, FrodoKEM, NTRU and composite ones in the BC provider, now raise the documented type - which extends IllegalArgumentException, so existing catches still match. The two RSA generators translate the lightweight refusal through a new SecurityExceptions.invalidParameterException factory.

... (truncated)

Commits

• See full diff in compare view

Updates org.bouncycastle:bcpkix-jdk18on from 1.84 to 1.86

Changelog

Sourced from org.bouncycastle:bcpkix-jdk18on's changelog.

Bouncy Castle Crypto Package - Release Notes

1.0 Introduction

The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms. The package is organised so that it contains a light-weight API suitable for use in any environment (including the J2ME) with the additional infrastructure to conform the algorithms to the JCE framework.

2.0 Release History

2.1.1 Version

Release: 1.87
Date: 2026, TBD

2.1.2 Defects Fixed

• A KeyAgreement asked for its shared secret before doPhase returned data rather than refusing. javax.crypto.KeyAgreement specifies IllegalStateException for that state, but nothing in the provider tracked it, so each SPI handed back whatever its result field held: for Diffie-Hellman that was the private value itself - engineInit seeded result with x, so generateSecret() returned the private exponent padded to the prime's length and generateSecret("AES") an all-zero key taken from that padding - while ECDH returned null and its named-algorithm overload raised NullPointerException. BaseAgreementSpi now records whether a doPhase has completed the agreement since the last init and refuses the request with an IllegalStateException naming the algorithm, so every family in the provider - DH, ECDH and ECMQV, the SM2 exchange, both ECGOST families, XDH, SM9 and NewHope - answers the same way, and the DH SPI no longer holds the private value in that field at all.

• Mac.getInstance and KeyGenerator.getInstance by the HMAC SHA-512/224 and SHA-512/256 object identifiers (1.2.840.113549.2.12 and .13) failed, although the same algorithms resolved by name and the matching SecretKeyFactory aliases were registered: the SHA512 mappings called addHMACAlgorithm for the two truncated variants without the addHMACAlias that registers their OIDs against Mac and KeyGenerator. Both are now aliased, as every other HMAC in that class already was.

• A KTSParameterSpec naming an HKDF key-derivation function with a parameters field - a form the provider does not service - was accepted at Cipher init and then failed out of wrap or unwrap with an unchecked IllegalStateException neither method declares. The KTS key-wrapping Ciphers (ML-KEM, Classic McEliece, FrodoKEM, the composite KEM and RSA-KEM) now validate the spec's KDF when they take it, reporting an unserviceable one as the InvalidAlgorithmParameterException engineInit declares, which is what the javax.crypto.KEM services already did through KdfUtil.resolveKemSpec.

• A DTLS handshake deadlocked when a handshake message ahead of the peer's ChangeCipherSpec (a client's CertificateVerify, say) was lost while the ChangeCipherSpec and Finished behind it arrived: the record layer moved its read epoch on at the ChangeCipherSpec and then discarded every retransmission of the lost message as belonging to the old epoch, whose records are only accepted once the handshake has completed. Each side then waited on the other until a handshake timeout, if one was configured, ended it. Every client-authenticated handshake, and every handshake in which the server issues a NewSessionTicket, was exposed. Until the handshake completes, handshake records from the current epoch are now still accepted after the read epoch has moved on, and each message is checked against the epoch of the record that carried it. The DTLS loopback tests now run their handshakes at 10% datagram loss in each direction, with a client-authenticated handshake at 25%.

• The lightweight SubjectPublicKeyInfoFactory and PrivateKeyInfoFactory encoded a GOST R 34.10-2012 key on one of the legacy CryptoPro curves under id-GostR3410-2001, although RFC 9215 sec. 4.2 permits those curves for 2012 keys. The digestParamSet now decides: a GOST R 34.11-94 parameter set means 2001 (RFC 4491 sec. 2.3.2), a GOST R 34.11-2012 digest or none means 2012 with 256/512 taken from the curve field size, and any other value is rejected. GOST3410PublicKeyAlgParameters treats digestParamSet as OPTIONAL on both read and write per RFC 9215, and PrivateKeyInfoFactory now passes attributes through for ECGOST3410 keys (bc-csharp github #707).

• The name-constraint host canonicalisation removed a single RFC 1034 root-label dot, the only empty label a name may legally carry, but nothing refused the ones that are not legal: a dNSName, rfc822Name host or uniformResourceIdentifier host such as "example.com.." kept a phantom empty label after the strip and so matched no constraint at all, escaping an excluded subtree naming the host it appears to carry. A tested name whose host carries an empty label - a second trailing dot, a doubled dot or a leading dot - is now refused outright wherever a constraint of that type is in force, rather than canonicalised into a name it is not: removing the extra dots would decide on the caller's behalf that "example.com.." names example.com, which is not how a consumer resolving or comparing the name reads it, and refusing fails closed in both directions where canonicalising would newly admit such a name under a permitted subtree. The single trailing dot is canonicalised as before, a bare "." remains the root label rather than an empty one, and the guard is scoped to the host, so the doubled dot a quoted local part may legally carry is unaffected. Constraints are untouched - one may still begin with a dot, which is how this implementation spells "subdomains only" (github PR #2436).

2.1.3 Additional Features and Functionality

2.1.4 Additional Notes

• The sources and javadoc jars of the Ant-built distributions (jdk14, jdk15to18 and jdk13) no longer carry test material. Each module's javadoc target copies the package documentation it needs - org/bouncycastle///*.html - back into the module source directory that has already been compiled from, and zip-src zips that directory afterwards, so every test package's package.html arrived in the sources jar by that route; javadoc-util additionally copied org/bouncycastle/asn1/isismtt//*.java, which put test classes into the bcutil javadoc as generated pages, and javadoc-pg deliberately copied the gpg and bcpg test sources in order to document them. Separately the source copies excluded test material only one directory deep and only for *.java, because Ant reads ** as an any-depth wildcard just where it is a whole path segment, so anything nested further or with another extension - the PEM certificate fixtures under org/bouncycastle/est/test/san corrected in 1.86, and an ICAO master list under org/bouncycastle/asn1/icao/test - went through. The source and javadoc copies of every module now exclude test directories at any depth, and javadoc-pg no longer documents the test packages. org.bouncycastle.util.test is unaffected and still ships in the bcprov binary, sources and javadoc jars, as it does from the Gradle build: it is the SimpleTest framework the light-weight API's own test classes are written against, not test material of the distribution. No binary changes - the classes and resources of every Ant-built jar are identical to those of the 1.86 release - and the Gradle-built jdk18on artifacts never carried any of this.

2.2.1 Version

Release: 1.86
Date: 2026, 11th September.

2.2.2 Defects Fixed

• The high-level OpenPGP API let a subkey inherit the primary key's Key Flags when its own Subkey Binding signature carried none, so a subkey bound with no flags counted as signing-capable for one check while the cross-certification check RFC 9580 sec. 5.2.1.8 requires of a signing subkey saw none and was skipped - letting a third party's public signing subkey be bound to an attacker's primary key and that party's genuine signatures verify under the attacker's identity. Flags are no longer inherited (CVE-2026-71887).
• The high-level OpenPGP API used a version 6 key carrying no valid Direct Key signature, falling back to the primary user ID binding as it correctly does for version 4. RFC 9580 sec. 5.2.3.10 requires the opposite, and since a v6 certificate carries its expiration and preferences there, stripping that one packet silently dropped them - the certificate went on offering subkeys of a key set to expire. isBoundBy now requires a valid Direct Key self-signature before any v6 component is treated as bound; version 4 is unaffected.
• The high-level OpenPGP API ignored the OpenPGPPolicy a caller had configured when verifying signatures on an inline message: OpenPGPMessageInputStream took the policy from the implementation's own default rather than from the processor doing the verification, so a hardened policy had no bearing on acceptance and getSignatures() reported isTestedCorrect() true for a signature that policy rejects. Both the one-pass and prefixed-signature paths now read the configured policy.
• The high-level OpenPGP API went on offering the subkeys of a certificate whose primary key had expired, the binding check evaluating only a subkey's own Subkey Binding signature - so the certificate contradicted itself, reporting the primary unbound while still handing out its subkeys. The primary key's expiration now applies to the whole certificate, as GnuPG and Sequoia treat it, and a subkey no longer inherits the primary's validity period, which RFC 9580 sec. 5.2.3.13 counts from the creation time of the key the carrying signature is made on.
• OpenPGPDocumentSignature.isValidAt(Date) reported a data signature as valid past the signature's own Signature Expiration Time (RFC 9580 sec. 5.2.3.18): it checked that the signature was correct and the issuing key bound and signing-capable at that date, but never the signature's own expiration, so it disagreed with isEffectiveAt() on the same object and with its own javadoc. isValid() and isValid(policy), which evaluate at creation time, are unchanged.
• The lightweight LMSSigner and HSSSigner refused a key wrapped in ParametersWithRandom, which is how BcContentSignerBuilder passes one once setSecureRandom() has been called, so BcHssLmsContentSignerBuilder failed with "Incorrect Key Parameters" and the two signers raised ClassCastException. All three now unwrap it, as the ML-DSA and SLH-DSA signers already did; the random is accepted and ignored, LMS deriving its message randomiser deterministically from the seed and one-time index.
• LMS signature verification did not apply two checks RFC 8554 sec. 5.4.2 requires before a signature is processed: step 2g, refusing a signature whose LMS typecode is not the public key's - without it a signature claiming a height-25 parameter set drove a 25-level computation against a height-5 key - and step 2i, refusing a leaf number outside the tree. Neither was a forgery, but both are attacker-chosen work the specification says to refuse up front. Both are now checked.
• The LMS and HSS key parameter classes now apply at construction the checks their decoders apply, so a key built directly cannot be one the decoder would refuse: LMSPrivateKeyParameters accepted an identifier of any length where the decoder reads exactly 16 bytes, and left q, maxQ and the seed length unchecked, while HSSPrivateKeyParameters checked neither its level count nor that it had a component key and chaining signature per level. The decoders now report a bad version or seed length as IOException rather than IllegalStateException.
• In the LMS JCE layer, LMSKeyGenParameterSpec.fromNames knew all twenty LMS parameter-set names but only four of the sixteen LM-OTS ones, so none of the SP 800-208 n24 or SHAKE sets could be named; all sixteen are now present. initialize(int, SecureRandom) now reports InvalidParameterException as the JCA specifies, and BCLMSPrivateKey.getIndex takes the exhaustion check and the index read under one monitor.
• KeyPairGenerator.initialize(int, SecureRandom) is documented to raise InvalidParameterException when the key size is not one the generator supports, and thirty of them raised a bare IllegalArgumentException instead. Every generator in BCPQC, and the ML-DSA, ML-KEM, SLH-DSA, Classic McEliece, FrodoKEM, NTRU and composite ones in the BC provider, now raise the documented type - which extends IllegalArgumentException, so existing catches still match. The two RSA generators translate the lightweight refusal through a new SecurityExceptions.invalidParameterException factory.

... (truncated)

Commits

• See full diff in compare view

Updates com.google.errorprone:error_prone_core from 2.40.0 to 2.50.0

Release notes

Sourced from com.google.errorprone:error_prone_core's releases.

Error Prone 2.50.0

New checks:

• BoxingComparator: Detect implicitly-boxing Comparator.comparing key extractors
• ExposedPrivateType: Discourage references to private member classes from non-private APIs
• JUnitMethodInvoked: Discourage directly invoking JUnit test methods
• ListRemoveAmbiguous: Detect ambiguous calls to List.remove(int|Integer)
• PreferTestParameter: suggests using @TestParameter instead of @TestParameters for exhaustive boolean and enum parameters on single-element parameterized tests
• RecordComponentAccessorAnnotationConflict: Detect conflicts between record components and explicit accessor methods
• RecordComponentOverride: Discourage @Override on record component declarations that don't override anything
• ThrowableEqualsHashCode: Discourage overriding Throwable.equals() and hashCode()

Closed issues: #5553, #5649, #5778

Full changelog: google/error-prone@v2.49.0...v2.50.0

Error Prone 2.49.0

This release includes several changes to Matcher APIs, and removed some deprecated or problematic APIs:

• Remove deprecated MethodMatchers.withSignature API, which relies on fragile toString behaviour. Alternatives for matching on method signatures with varargs and type parameters were added in google/error-prone@a98a1c5.
• Removed variableType(Matcher) API. Matchers.variableType(Matcher) uses VariableTree#getType to match variable types, which own't work for lambda parameters with inferred types after JDK-8268850. The recommended replacement is variableType(TypePredicate).
• Make enclosingPackage return an optional. Module elements are not enclosed by a package, checks using enclosingPackage shouldn't assume an enclosing package exists when processing arbitrary elements.
• New FieldMatchers API, similar to MethodMatchers (google/error-prone@1dd9c3a).

New checks:

• AssertThrowsBlockToExpression: Discourage unnecessary block lambdas in assertThrows.
• AssertThrowsMinimizer: Suggest minimizing the amount of logic in assertThrows.
• MemorySegmentReferenceEquality: Discourage using reference equality for MemorySegments.
• PreferThrowsTag: Recommends using @throws instead of the legacy @exception javadoc tag.
• RecordAccessorInCompactConstructor: detect record accessors inside the compact canonical ctors, which read uninitialized fields.

Closed issues: #2283, #3503, #5210, #5289, #5548, #5548, #5554, #5609, #5614, #5656

Full changelog: google/error-prone@v2.48.0...v2.49.0

Error Prone 2.48.0

Changes:

• Added support for passing flags with command-line argument files (@-files) (google/error-prone@8e84edf)

New checks:

• AvoidValueSetter
• UnnecessarySemicolon

Closed issues: #5529, #5537, #5522, #5521

Full changelog: google/error-prone@v2.47.0...v2.48.0

... (truncated)

Commits

• d802cff Release Error Prone 2.50.0
• b12b5f2 In StringCharset, move the description from explanation to summary.
• a7ca02a Update AssertThrowsUtils to emit var thrown = assertThrows(...) instead o...
• 6b56517 Fix handling of nested tags in UnrecognisedJavadocTag
• d36e74f Remove translation of the fail() message into assertThrows(). We already ...
• c3581e9 Fix JavacFileManager compiler crash during speculative recompiles in modular ...
• da1f32b Remove assignments from assertThrows() lambdas. A large percentage of remai...
• dee62f7 Update AssertThrowsBlockToExpression to re-write single VariableTrees int...
• 4939448 Only hoist the last statement into the assertThrows() lambda.
• 30fd05a refactor: Rename JavaLangClash bug pattern to AvoidCommonTypeNames
• Additional commits viewable in compare view

Updates com.uber.nullaway:nullaway from 0.12.7 to 0.14.1

Release notes

Sourced from com.uber.nullaway:nullaway's releases.

NullAway 0.14.1

Several bug fixes in this release, particularly for JSpecifyExperimental. Thanks to all who tested out this mode, reported bugs, and contributed! Please continue to test and send feedback. See the 0.14.0 release notes below for more information on JSpecifyExperimental.

• Fix restoring nullness annotations from an unbounded wildcard to a captured type (#1717)
• JSpecify: support anonymous diamond classes by @​subhramit (#1710)
• Fix attribute errors reported during dataflow (#1736)
• Apply library models to an overridden method type when checking overrides (#1722)
• Deduplicate generic inference failure warnings (#1741)
• Preserve nested nullness annotations through inheritance (#1742)
• Fix crash for generic qualifiers in method references (#1744)
• Cache immutable stubx library models (#1745)
• Allow nullable method references for void functions (#1747)
• Preserve nested nullness in enhanced-for variable types (#1748)
• Track nullable elements in enhanced-for dataflow (#1749)
• Honor ignored methods in null-marked library models (#1753)
• Avoid crashes on malformed @Contract arity (fixes #1726) (#1756)
• Inherit null-implies-null models across overrides (#1758)
• Fix inference for annotated type variable uses (#1759)
• Preserve contract unreachability across store joins (#1761)
• Prevent recursion on self-referential wildcard bounds (#1763)
• Work around pre-JDK-25 limitations in reading upper bounds from wildcard arguments in bytecode (#1764)
• Improve diagnostics for non-null type variable bounds (#1770)
• Fix override checks for method type variables bounded by a class type variable by @​pivovarit (#1775)
• Maintenance
  • Migrate FrameworkTests to addSourceLines by @​abdeltaehass (#1712)
  • Attribute errors reported during dataflow to the right file by @​vlsi (#1734)
  • Disable CodeRabbit summaries (#1755)
  • Add tests for overrides of Collection.toArray (#1757)
  • Assert the full set of diagnostics for annotated type-variable uses by @​vlsi (#1768)
  • Document that a nullImpliesNull model applies to overriding methods by @​vlsi (#1771)
  • Add tests for the JSpecify nullness operator by @​vlsi (#1767)

NullAway 0.14.0

This release has significant improvements to JSpecify support, including improved support for wildcards and integration of the standard library nullability annotations from https://github.com/jspecify/jdk. Much of this new support is gated behind a new JSpecifyExperimental flag, which is off by default. We disable the flag by default since this new support leads to many new errors in existing projects (mostly from the new JDK models), and because we need more real-world testing before enabling it by default. We encourage projects to enable the JSpecifyExperimental flag (alongside JSpecify mode) and to report any issues that arise. We expect to turn JSpecifyExperimental on by default in a future release.

Aside from the above, you may observe some newly reported warnings in JSpecify mode, due to other checking improvements.

... (truncated)

Changelog

Sourced from com.uber.nullaway:nullaway's changelog.

Version 0.14.1

Several bug fixes in this release, particularly for JSpecifyExperimental. Thanks to all who tested out this mode, reported bugs, and contributed! Please continue to test and send feedback. See the 0.14.0 release notes below for more information on JSpecifyExperimental.

• Fix restoring nullness annotations from an unbounded wildcard to a captured type (#1717)
• JSpecify: support anonymous diamond classes by @​subhramit (#1710)
• Fix attribute errors reported during dataflow (#1736)
• Apply library models to an overridden method type when checking overrides (#1722)
• Deduplicate generic inference failure warnings (#1741)
• Preserve nested nullness annotations through inheritance (#1742)
• Fix crash for generic qualifiers in method references (#1744)
• Cache immutable stubx library models (#1745)
• Allow nullable method references for void functions (#1747)
• Preserve nested nullness in enhanced-for variable types (#1748)
• Track nullable elements in enhanced-for dataflow (#1749)
• Honor ignored methods in null-marked library models (#1753)
• Avoid crashes on malformed @Contract arity (fixes #1726) (#1756)
• Inherit null-implies-null models across overrides (#1758)
• Fix inference for annotated type variable uses (#1759)
• Preserve contract unreachability across store joins (#1761)
• Prevent recursion on self-referential wildcard bounds (#1763)
• Work around pre-JDK-25 limitations in reading upper bounds from wildcard arguments in bytecode (#1764)
• Improve diagnostics for non-null type variable bounds (#1770)
• Fix override checks for method type variables bounded by a class type variable by @​pivovarit (#1775)
• Maintenance
  • Migrate FrameworkTests to addSourceLines by @​abdeltaehass (#1712)
  • Attribute errors reported during dataflow to the right file by @​vlsi (#1734)
  • Disable CodeRabbit summaries (#1755)
  • Add tests for overrides of Collection.toArray (#1757)
  • Assert the full set of diagnostics for annotated type-variable uses by @​vlsi (#1768)
  • Document that a nullImpliesNull model applies to overriding methods by @​vlsi (#1771)
  • Add tests for the JSpecify nullness operator by @​vlsi (#1767)

Version 0.14.0

This release has significant improvements to JSpecify support, including improved support for wildcards and integration of the standard library nullability annotations from https://github.com/jspecify/jdk. Much of this new support is gated behind a new JSpecifyExperimental flag, which is off by default. We disable the flag by default since this new support leads to many new errors in existing projects (mostly from the new JDK models), and because we need more real-world testing before enabling it by default. We encourage projects to enable the JSpecifyExperimental flag (alongside JSpecify mode) and to report any issues that arise. We expect to turn JSpecifyExperimental on by default in a future release.

... (truncated)

Commits

• b3d442a Prepare for release 0.14.1.
• d6df98b Release notes for 0.14.1 (#1784)
• ecb763e fix override checks for method type variables bounded by a class type variabl...
• 915b287 Add tests for the JSpecify nullness operator (#1767)
• f142e85 Improve diagnostics for non-null type variable bounds (#1770)
• bb5cf51 Work around pre-JDK-25 limitations in reading upper bounds from wildcard argu...
• 17d7ca7 Document that a nullImpliesNull model applies to overriding methods (#1771)
• cc156e4 Assert the full set of diagnostics for annotated type-variable uses (#1768)
• b9efa0f Prevent recursion on self-referential wildcard bounds (#1763)
• 177ad18 Preserve contract unreachability across store joins (#1761)
• Additional commits viewable in compare view

Updates com.nimbusds:nimbus-jose-jwt from 10.4 to 10.9.1

Changelog

Sourced from com.nimbusds:nimbus-jose-jwt's changelog.

10.4 (2025-07-19) * Creates a hierarchy of Option interfaces, extended by JWSSignerOption, JWEEncrypterOption and JWEDecrypterOption. Intended to provide optional configuration parameters to RSASSASigner, ECDSASigner, RSADecrypter, etc. * Introduces CipherMode implementing JWEEncrypterOption and JWEDecrypterOption, to specify a preferred JCA Cipher mode, such as MODE_ENCRYPT / MODE_DECRYPT when the default MODE_WRAP / MODE_UNWRAP is not supported by the JCA provider (iss #576). * Updates RSAEncrypter and RSADecrypter to support the JWEEncrypterOption CipherMode.ENCRYPT_DECRYPT (iss #576). * Factors out OptionUtils.ensureMinRSAPrivateKeySize. * Deprecates OptionUtils.optionIsPresent.

10.4.1 (2025-08-05) * Adds "requires java.sql" to module com.nimbusds.jose.jwt (iss #595).

10.4.2 (2025-08-14) * Updates GSon to 2.13.1. * Updates BouncyCastle to 1.81.

10.5 (2025-09-05) * Support for specifying a ScheduledExecutorService instance in RefreshAheadCachingJWKSetSource and JWKSourceBuilder (iss #592).

10.6 (2025-11-06) * Adds static CollectionUtils.containsNull(Set) method. * DefaultJWTClaimsVerifier accepted "aud" (audience) argument must be compatible with Set.of (iss #499). * The DefaultJWTClaimsVerifier must not include JWT claim values in BadJWTException messages (iss #605).

10.7 (2026-01-08) * Adds MaxCompressedCipherTextLength that implements JWEDecrypterOption, to to configure the maximum allowed length of compressed cipher text. * Adds JWEObject.decrypt(JWEDecrypter, Set) method to support the MaxCompressedCipherTextLength option.

10.8 (2026-02-19) * Adds a PasswordBasedDecrypter(byte[], Set) constructor to specify names of the critical header parameters that are deferred to the application for processing. Aligns with other JWEDecrypter and CriticalHeaderParamsAware implementations (iss #610). * Fixes getDeferredCriticalHeaderParams() in AESDecrypter, DirectDecrypter, RSADecrypter, ECDHDecrypter, X25519Decrypter, ECDH1PUDecrypter, ECDH1PUX25519Decrypter, MultiDecrypter, MACVerifier, ECDSAVerifier and Ed25519Verifier. Must internally call critPolicy.getDeferredCriticalHeaderParams(), not critPolicy.getProcessedCriticalHeaderParams() (iss #612).

10.9 (2026-04-02)

... (truncated)

Commits

• b33b54b Bumps GSon and BouncyCastle
• 3eeaada [maven-release-plugin] prepare release 10.4.2
• 2aa473f [maven-release-plugin] prepare for next development iteration
• d52acf5 Merged in iss592 (pull request #129)
• d1834c6 JWKSourceBuilderTest must target Java 7
• 5fb46ee Change log for 10.5, JavaDoc edits (iss #592)
• 724be14 RefreshAheadCachingJWKSetSource JavaDoc markup fix (iss #592)
• 6be3a17 [maven-release-plugin] prepare release 10.5
• dacdb14 [maven-release-plugin] prepare for next development iteration
• d5b9c10 Documents truncation and rounding for float and double getters in JWTClaimsSet
• Additional commits viewable in compare view

Updates com.nimbusds:oauth2-oidc-sdk from 11.26 to 11.38.2

Changelog

Sourced from com.nimbusds:oauth2-oidc-sdk's changelog.

version 1.0 (2012-05-29) * First official release with authorisation endpoint, token endpoint, check ID endpoint and UserInfo endpoint support. * JSON Web Tokens (JWTs) support through the Nimbus-JWT library. * Language Tags (RFC 5646) support through the Nimbus-LangTag library. * JSON support through the JSON Smart library.

version 2.0 (2013-05-13) * Intermediary development release with Maven build, published to Maven Central.

version 2.1 (2013-06-06) * Updates the APIs to OpenID Connect Messages draft 20, OpenID Connect Standard draft 21, OpenID Connect Discovery draft 17 and OpenID Connect Registration draft 19. * Major refactoring of the APIs for greater simplicity. * Adds JUnit tests.

version 2.2 (2013-06-18) * Refactors dynamic OpenID Connect client registration. * Adds partial support of the OAuth 2.0 Dynamic Client Registration Protocol (draft-ietf-oauth-dyn-reg-12). * Optimises parsing of request parameters consisting of one or more tokens (scope, response type, etc).

version 2.3 (2013-06-19) * Renames OAuth 2.0 dynamic client registration package. * Adds ClientInformation.getClientMetadata() method. * Adds OIDCClientInformation class.

version 2.4 (2013-06-20) * Adds static OIDCClientInformation.parse(JSONObject) method.

version 2.5 (2013-06-22) * Adds support OAuth 2.0 dynamic client update. * Adds OpenID Connect dynamic client registration classes.

version 2.6 (2013-06-25) * Enforces order of preference of ACR values in OpenID Connect client metadata, as required by the specification. * Documentation and performance improvements.

version 2.7 (2013-06-26) * Switches Identifier generation to java.security.SecureRandom.

version 2.8 (2013-06-30) * Fixes serialisation and assignment bugs in ClientMetadata. * Switches Secret generation to java.security.SecureRandom.

version 2.9 (2013-09-17)

... (truncated)

Commits

• fac7277 Bumps Nimbus JOSE+JWT, BouncyCastle
• 517deb7 [maven-release-plugin] prepare release 11.37.1
• fedf633 [maven-release-plugin] prepare for next development iteration
• 29b77a0 Updates to JSON Smart 2.6.0
• 6e53206 [maven-release-plugin] prepare release 11.37.2
• bbd0e83 [maven-release-plugin] prepare for next development iteration
• 02b80a2 Adds SubjectType.EPHEMERAL enum constant (iss #560)
• 15d3318 Downloads current connect2id-com-chain.pem
• 6a7c5d3 Fixes pom.xml scm tag
• 6ed944d [maven-release-plugin] prepare release 11.38
• Additional commits viewable in compare view

Updates org.apache.httpcomponents.client5:httpclient5 from 5.6.3 to 5.6.4

Changelog

Sourced from org.apache.httpcomponents.client5:httpclient5's changelog.

Release 5.6.4

This maintenance release fixes SSL parameter application in the async TLS upgrade strategy.

Change Log

• BearerScheme to reject control characters in bearer token. Contributed by Javid Khan

• Corrects application of SSL parameters in the async TLS upgrade method. Contribute...

  Description has been truncated