Repository navigation
Tags
Tags
Repoint MigrateToGradle9 at rewrite-migrate-gradle (#1446) `org.openrewrite.gradle.MigrateToGradle9` is being removed from rewrite-gradle in openrewrite/rewrite#9796; the recipe now lives in rewrite-migrate-gradle as `org.openrewrite.gradle.migrate.MigrateToGradle9`. `UpgradeToJava25` composed the core id, so point it at the new one and add the runtime dependency that provides it. The reference is YAML-only, so `runtimeOnly` is enough. Every other `org.openrewrite.gradle.*` recipe this repository composes (`UpdateGradleWrapper`, `AddDependency`, `plugins.*`, `ChangeDependency*`) stays in core and is untouched.
Limit the beans.xml, validation.xml and orm.xml migrations to older d… …escriptors (#1444) * Skip `beans.xml` files outside the CDI namespaces in `BeanDiscovery` * Limit the beans.xml, validation.xml and orm.xml migrations to older descriptors * Retrigger CI with rewrite-maven snapshot containing openrewrite/rewrite#9816 --------- Co-authored-by: Tim te Beek <tim@moderne.io>
Migrate Mockito 2 to 4 APIs when UpgradeToJava25 upgrades to Mockito 5 ( #1442) * Migrate Mockito 2 to 4 APIs when UpgradeToJava25 upgrades to Mockito 5 UpgradePluginsForJava25 upgrades every directly declared Mockito to 5.20.x, but the API migration in UpgradeMockito1ForJava25 only ran for Mockito 1. Modules on Mockito 2 to 4 still using APIs removed in Mockito 5, such as `Matchers` or `anyListOf`, no longer compiled after the upgrade. Widen the precondition to Mockito 1 to 4 so Mockito1to5Migration runs before the version bump. The Mockito 1 matcher null-semantics migration stays limited to mockito-all. * Cover matcher null semantics when upgrading Mockito 2 to 4 Modules on Mockito 2 to 4 now run the Mockito 1 to 5 migration, which must keep `any(Class)` instead of turning it into `nullable(Class)`, as only Mockito 1 matched null there. Add a test for a Mockito 3 module and drop an assertion that held without the change. * Share the mockito-core POM in UpgradeLegacyMockitoForJava25Test * Apply OpenRewriteRecipeBestPractices to UpgradeLegacyMockitoForJava25Test
Replace `checkNotNull` with a message template by `requireNonNull` an… …d a `Supplier` (#1433) * Keep Guava functional types and Optional where a called API still needs them Changing com.google.common.base.Function, Supplier and Optional to the JDK types broke files that pass them to Guava, like Lists.transform(list, function) or Suppliers.memoize(supplier), or that get a Guava Optional from Iterables.tryFind. NoGuavaPredicate only checked a Predicate in the last parameter. DoesNotRequireGuavaType now decides per file whether a type can be replaced. The Predicates.and/or/not/equalTo and Functions.compose conversions run under the same decision, since they produce JDK types that only fit once the type changes. * Count the conversions moved into PreferJavaUtilFunction and PreferJavaUtilPredicate * Keep NoGuava's output compiling below the Java version an API needs On Java 8, NoGuava produced Stream.toList(), Optional.stream(), Predicate.not(), String.repeat() and InputStream.readAllBytes()/transferTo(), and turned Optional.or(Optional) into orElse(Optional). Iterables.filter, Optional.asSet, Optional.or(Optional) and Predicates.not now use Java 8 forms below the version their usual replacement needs. The inlined @InlineMe methods and Picnic's InputStream rules, which can't be gated one by one, move into NoGuavaJava11, except skipNBytes, which moves into NoGuavaJava21. * Mark the JDK exemption in DoesNotRequireGuavaType as a workaround ChangeMethodName, ChangeType and ChangeMethodTargetToStatic keep the old method's parameter types, so the precondition has to trust that a JDK method never takes a Guava type. * Mark the Java 11 gate on InlineGuavaMethods as a generator workaround The generated recipes carry no Java version precondition, and five of them need Java 9 or 11. * Keep the filtered set's order and comparator when converting Sets.filter The SortedSet overload collected into TreeSet::new, dropping the source's comparator, and the Set overload into Collectors.toSet(), dropping the source's iteration order. Collect into new TreeSet<>(set.comparator()) when the set can be read a second time, and into a LinkedHashSet otherwise. * Decide the Predicate swap after converting Predicates calls, not before The composite excused every `Predicates.and`, `or`, `not` and `equalTo` call, but `NoGuavaPredicatesAndOr` keeps some of them, such as `Predicates.and(isA, Predicates.notNull())`. `NoGuavaPredicate` then refused the swap while `Predicate.isEqual(..)` had already replaced a Guava-typed initializer, which does not compile. `NoGuavaPredicate` now runs the four conversions itself, checks the converted file, and keeps the result only when nothing still requires a Guava `Predicate`. `PreferJavaUtilPredicate` lists only `NoGuavaPredicate`. * Keep the Java 8 forms compiling when the argument's type parameter differs Guava's `Predicates.not` takes a `Predicate<? super T>` and `Optional.or` an `Optional<? extends T>`. Below Java 11, `Predicates.not(isNull)` with a `Predicate<Object>` assigned to a `Predicate<String>` stays, since `isNull.negate()` keeps `Object`. Below Java 9, an `Optional<Integer>` fallback for an `Optional<Number>` becomes `Optional.ofNullable(first.orElse(second.orElse(null)))`, since `orElse(second)` needs the same type. The Java 8 test for a kept lambda also has a variable `not` in the same file, which keeps the whole file on Guava, and a method reference on its own. The `NoGuavaIterablesAnyFilter` description mentions the `Iterables.filter` conversion. * Keep the type arguments of Guava's no-argument collection factories NoGuava turned Lists.<String>newArrayList() into new ArrayList<>(), whose diamond infers Object where nothing gives a target type, as when the new list is the receiver of a call. Replace such calls with the constructor and the same type arguments before the Refaster rules run. * Keep Guava's Optional where a static method has no java.util.Optional counterpart Changing the type moves `Optional.presentInstances(..)` onto `java.util.Optional`, which has no such method. Running NoGuava over the sample app from #928 left it as one of two compile errors. Static methods of the Guava type now count as requiring it unless the composite lists them as replaced, and `PreferJavaUtilOptional` lists `absent`, `of`, `fromNullable` and `fromJavaUtil`. * Replace checkNotNull with a message template by requireNonNull and a Supplier NoGuava left Preconditions.checkNotNull(reference, template, args..) in place. Turn it into requireNonNull(reference, () -> String.format(template, args..)), which formats the message only when the reference is null, as Guava does, when the template uses only %s placeholders matching the arguments and the lambda can capture every argument. The capture check moves out of NoGuavaSetsFilter into LambdaCapture, which both recipes use. * Keep Sets.filter on a wildcard-typed sorted set, and convert the NavigableSet overload With `SortedSet<? extends Number> set`, the comparator supplier's second read of `set` gets its own capture type, so `.collect(toCollection(() -> new TreeSet<>(set.comparator())))` does not compile. Such calls keep `Sets.filter`. Guava's `filter(NavigableSet, Predicate)` overload matched neither matcher and now converts like the `SortedSet` one, since `TreeSet` is a `NavigableSet`. * Run the type-argument factories before InlineGuavaMethods, and qualify on name clashes `InlineGuavaMethods` inlines `Lists.newCopyOnWriteArrayList()` to a diamond, so `Lists.<String>newCopyOnWriteArrayList().iterator()` still lost its type argument. The recipe now runs first in `NoGuava`. The constructor is written in full and shortened afterwards, so a file that imports its own `HashMap` gets `new java.util.HashMap<String, Integer>()`. * Capture nothing outside a method, see parenthesized reassignments, and keep this.field in Sets.filter - A message whose arguments read no variable converts in a field initializer too, since there is nothing to capture. - `(i)++` and `(key) = other` count as reassignments, so such a variable is not captured. - `Sets.filter(this.set, p)` converts wherever it appears, as before `LambdaCapture`, since a lambda can always read a field through `this`. * Correct the NoGuava and JavaBestPractices recipe counts Pull requests that each raised these counts by one merged as the same edit, so recipes.csv lost some of the increments. The counts now match what recipeCsvGenerate computes for NoGuava.
Constrain guava past CVE-2026-102554 (#1415) Constrain com.google.guava:guava to 33.8.0-jre, which fixes CVE-2026-102554 (GHSA-xxph-c9ww-hj94).
Keep Spring Boot annotation processors when Lombok creates `annotatio… …nProcessorPaths` (#1410) * Keep Spring Boot annotation processors when Lombok creates `annotationProcessorPaths` Explicit processor paths turn off classpath discovery, so a module that declared `spring-boot-configuration-processor` stopped generating configuration metadata. * Simplify AddSpringBootAnnotationProcessorPaths and skip work on non-target files
PreviousNext