Repository navigation
Tags: openrewrite/rewrite-migrate-java
Tags
Add a `FlagUsage` recipe to stop Lombok's `val`/`var` from coming back ( #1244) * add lombok flag usage recipes * Replace FlagUsage subclasses with a single option-driven recipe * Take a feature name and an optional value in FlagUsage * Trim the FlagUsage description and name instances by the line they write * Trim the javadoc on the lombok.config assignment helpers --------- Co-authored-by: Tim te Beek <tim@moderne.io>
Do not run `ExtractExplicitConstructorInvocationArguments` on non-Jav… …a sources (#1235) The recipe's `JavaIsoVisitor` accepted any `JavaSourceFile`, so it also ran on Groovy compilation units. There it reached `JavaTemplate`, which generates its stub from the Groovy LST and parses it as Java, and `JavaTemplateParser.parseMethodArguments` threw on the result. Narrow the visitor to `J.CompilationUnit`. JEP 513 is a Java language feature, so Groovy and Kotlin sources are out of scope for this recipe.
Drop the `rewrite-analysis` dependency from `URLConstructorToURICreat… …e` (#1226) * Drop the `rewrite-analysis` dependency from `URLConstructorToURICreate` A single recipe pulled in the whole module, only to resolve a `String` identifier back to the literal it was initialized with. Walking the enclosing blocks for the matching variable declaration covers the fields and locals that the recipe actually sees, and it drops the `RecipeRunException` catch that was there solely because `ConstantFold` throws on a lambda parameter. The lookup is by name rather than by dataflow, so a variable reassigned before use, or shadowed elsewhere, can now fold to a different value. That only shifts whether the path is judged valid; the argument is passed through to `URI.create` untouched either way. * Resolve the identifier by type, and refuse to fold a reassigned variable Matching the declaration on its name alone crossed two boundaries the previous `ConstantFold` respected. A local shadowing a field is a distinct variable, so comparing `JavaType.Variable` — which carries the owner — keeps the walk going past the shadowing declaration to the one the identifier actually binds to. And a variable written to anywhere in the file no longer holds the value it was declared with, which is the condition `ConstantFold` expressed as a single assigned value. An assignment through `this` reaches the same variable as a bare name, so the target is unwrapped before comparing.
Extend `UseListOf` prose pattern to `LinkedHashSet` (#1181) (#1209) A `new LinkedHashSet<>()` declaration followed by a chain of `add(..)` calls now collapses to `new LinkedHashSet<>(List.of(..))`, keeping the constructed type rather than replacing it. Routing through `List.of` avoids the ordering and duplicate concerns that made #1181 reject `LinkedHashSet` for `UseSetOf`. The add matcher widens from `java.util.List add(..)` to `java.util.Collection add(..)`, since `Set.add` does not override `List.add`.
Bump Kotlin 2.0-2.2 to 2.3 so Kotlin modules can reach Java 25 (#1139) * Bump Kotlin 2.0-2.2 to 2.3 so Kotlin modules reach Java 25 * Floor Kotlin 2.0-2.2 modules at Java 24 as a bump safety net * Explain the Java 24 safety-net floor in UpgradeKotlinForJava25 * Rename UpgradeBuildToJava24 to UpgradeBuildToJava24ForKotlin1x * Comment both Kotlin 1.x caps and 2.x bump-fallbacks left at Java 24 Make CommentJava24KotlinCap self-healing (add at Java 24, remove once the module reaches a higher version) and run it last via a new CommentKotlinModulesCappedAtJava24 wrapper scoped to Kotlin modules, so the explanation lands on every Kotlin module that truly stays at Java 24 without leaving a stale comment on modules that reach Java 25.
PreviousNext