Co-authored-by: Moderne <[email protected]>

* Adopt upstream XML trailing-comment formatting

openrewrite/rewrite#8353 made XML auto-format keep a comment on the same
line as the element it trails, instead of reflowing it onto its own line.

`AddMockitoJavaAgentToMavenSurefirePlugin` relied on that reflow: when its
`<argLine>` is appended into an existing `<configuration>`, the accompanying
`<!--suppress MavenModelInspection -->` is no longer the first content of the
tag, so it stayed glued to the preceding sibling and read as annotating that
element rather than the `<argLine>` below it. Seed the comment with a newline
prefix so auto-format keeps it on its own line either way.

`JpaCachePropertiesTest` expectations reflowed comments that the input had
placed on the same line; they now assert the input's own placement.

* Revert JpaCachePropertiesTest expectations to own-line comments

Restores the pre-existing expectations, which assert that auto-format moves
a trailing comment onto its own line. All 20 cases fail against the current
rewrite snapshot: openrewrite/rewrite#8353 now keeps such comments on the
line of the element they trail.

Leaving the expectations as the desired behaviour rather than absorbing the
new output into the test. Red until the formatting is addressed.

* Route JpaCacheProperties removals through RemoveContentVisitor

openrewrite/rewrite#8355 taught `RemoveContentVisitor` to hand a removed
element's prefix to a comment that trailed it, so the comment keeps its own
line instead of collapsing onto the preceding sibling. `JpaCacheProperties`
removed via `filterTagChildren`, which drops content outright and so never
saw that fix; switching the two single-element removals over picks it up and
restores the original expectations for 13 of the 20 cases.

The remaining 7 remove nothing: the element the comment trails is retained
(or merely has an attribute updated), so #8353 now faithfully reproduces the
inline placement the input used. Those expectations were asserting the old
reflow and are updated to match the source.

Co-authored-by: Tim te Beek <[email protected]>

Co-authored-by: Moderne <[email protected]>

Co-authored-by: Moderne <[email protected]>

`LinkedHashSet` matched the `new HashSet<>()` constructor matcher, so an
ordered set built with `add(..)` statements was rewritten to
`new HashSet<>(Set.of(..))`: uncompilable against the `LinkedHashSet`
declared type, and dropping the iteration-order contract. Mirrors the
`UseMapOf` guards added for #1113 and #1163.

The nightly SDKMAN! candidates refresh added 21.0.12-tem, breaking the
hardcoded 21.0.11-tem expectation. Assert on the version basis and
distribution instead, matching the surrounding tests.

…p it minimal (#1184)

* Add tests for surefire argLine late replacement only when needed

* Only add surefire argLine late replacement when something sets the property

* Make AddMockitoJavaAgentToMavenSurefirePlugin opt-in rather than part of UpgradeToJava25

* Add AddMockitoJavaAgentToMavenSurefirePlugin to Java best practices

* Use reduce() to collect JaCoCo plugin declaration

* Trim javadoc

* Restore AddMockitoJavaAgentToMavenSurefirePlugin in UpgradeToJava25

…1185)

`com.fasterxml.jackson.jaxrs.json` -> `com.fasterxml.jackson.jakarta.rs.json`
omits `recursive` while depending on it, so types in the `.annotation`
subpackage were never migrated.

Verified against the published artifacts:

    jackson-jaxrs-json-provider 2.14.3       -> jackson-jakarta-rs-json-provider 2.15.4
      com.fasterxml.jackson.jaxrs.json.annotation -> com.fasterxml.jackson.jakarta.rs.json.annotation

The subpackage maps exactly under prefix substitution, so recursion is both
safe and required here.

The existing tests could not catch this. `ChangePackage.recursive` is
`@Nullable` with no documented default, and a null was read as non-recursive
by the recipe's preconditions but as recursive by its visitor, so a subpackage
type was renamed only for files that also referenced a type sitting directly
in `oldPackageName`. The new test imports only `...jaxrs.json.annotation.JSONP`
and fails without this change.

Co-authored-by: Moderne <[email protected]>

The nightly SDKMAN! candidates refresh rolled 17.0.19 to 17.0.20 and
11.0.31 to 11.0.32, which broke `updateVersionExact` and
`updateDistributionOnly` on every open pull request.

Unlike #1183 these two tests pin a patch version on their input as well
as their expectation, so asserting on the version basis alone is not
enough; the recipe finds no candidate to upgrade to and makes no change
at all. Read a currently available patch version from the same candidate
list the recipe resolves against instead.

…pe (#1187)

* Fix UseVarForObject with generic method return types

* Detect method-level type variables through the method declaration

Determine whether the return type variable is declared by the method
itself via `getDeclaredFormalTypeNames()`, rather than by comparing its
name against the declaring class' type parameters. This also covers a
method type variable shadowing a class type variable of the same name.

Unwrap array return types repeatedly, so that multi dimensional arrays
such as `<T> T[][] method()` are detected as well.

Only resolve the method declaration when the cheaper checks have not
already rejected the declaration, as the lookup walks the supertype and
interface hierarchy.

* Resolve the declared method without relying on signature matching

`TypeUtils.findDeclaredMethod` cannot match a signature whose declared
parameters mention a type variable, as the invocation's parameter types
are resolved while the declaration's are not. Generic methods declared on
a generic type, such as `interface Cache<K> { <T> T get(K key); }`, were
therefore never found and slipped past the check.

Look up candidate declarations by name and arity across the declaring
type, its supertypes and its interfaces instead, and treat a method as
unresolvable when one of its own type parameters occurs in the declared
return type but in none of the declared parameter types. Occurrence
checking recurses through arrays, type arguments and generic bounds.

* Short circuit the applicability checks

Inline the conditions into their `if` statements, such that the cheaper
checks can reject a declaration before the more expensive ones run.

---------

Co-authored-by: Tim te Beek <[email protected]>

Co-authored-by: Moderne <[email protected]>

* Cover legacy Bouncy Castle artifacts and their API changes

The `jdk18on` recipe only handled `-jdk15on` and `-jdk15to18`, and neither
recipe touched code, leaving callers on a dependency that no longer compiles.

Dependency coordinates:
- Migrate `-jdk12`, `-jdk14`, `-jdk15`, `-jdk15+` and `-jdk16` to `-jdk18on`,
  for every artifact where both sides are published.
- Add the `bcprov-ext` counterparts to the existing `-jdk15on` and
  `-jdk15to18` migrations.

API changes between 1.70 and 1.85:
- `BouncyCastleDerStringGetInstanceReturnType` widens declared types to
  `ASN1*String` where the value comes from `DER*String.getInstance(..)`,
  which 1.71 pulled up to the supertype.
- `BouncyCastleSphincsPlusToPqcLegacy` renames the SPHINCS+ package that
  1.78 moved to `pqc.legacy` to make room for SLH-DSA.

* Use @valuesource for the artifact base name parameters

* Migrate bctsp onto bcpkix, and legacy suffixes for Java < 8

Both were called out as follow-ups on the PR; ChangeDependency already
collapses duplicate coordinates, so the bctsp mapping needs nothing extra.

- Map `bctsp-*` onto `bcpkix`, which absorbed the time stamp protocol
  support in 1.47, in both the `jdk18on` and `jdk15to18` recipes. A pom
  holding both `bctsp-jdk15on` and `bcpkix-jdk15on` collapses to a single
  `bcpkix-jdk18on` dependency, which is pinned by a test.
- Mirror the `-jdk12`, `-jdk14`, `-jdk15`, `-jdk15+` and `-jdk16` migrations
  onto `-jdk15to18` for the Java < 8 recipe.

…k.NotNull` (#1190)

Co-authored-by: Moderne <[email protected]>