-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add explicit imports to avoid conflicts with classes added to java.lang
, like Record
#540
Comments
This is something to be included on the "Migrate to Java 17" recipe or will be standalone recipe? |
I'd implement this as a recipe that takes in an argument, which we then add to the Java 17 and 21 migrations. |
As a quick starter; here's how we'd test this type of recipe import org.junit.jupiter.api.Test;
import org.openrewrite.DocumentExample;
import org.openrewrite.java.JavaParser;
import org.openrewrite.test.RewriteTest;
import static org.openrewrite.java.Assertions.java;
import static org.openrewrite.java.Assertions.javaVersion;
class AvoidConflictingImportsTest implements RewriteTest {
@Override
public void defaults(RecipeSpec spec) {
try {
JavaParser.Builder<? extends JavaParser, ?> parser = ((JavaParser.Builder<? extends JavaParser, ?>) Class
.forName("org.openrewrite.java.Java11Parser")
.getDeclaredMethod("builder")
.invoke(null));
spec.recipe(new AvoidConflictingImports("java.lang.Record"))
.parser(parser);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
@DocumentExample
@Test
void importFromSamePackage() {
rewriteRun(
//language=java
java(
"""
package com.acme.bank;
public class Record {}
"""
),
//language=java
java(
"""
package com.acme.bank;
class Foo {
Record r;
}
""",
"""
package com.acme.bank;
import com.acme.bank.Record;
class Foo {
Record r;
}
""",
spec -> spec.markers(javaVersion(11))
)
);
}
private static JavaParser.Builder<? extends JavaParser, ?> java8Parser() throws Exception {
return ((JavaParser.Builder<? extends JavaParser, ?>) Class
.forName("org.openrewrite.java.Java11Parser")
.getDeclaredMethod("builder")
.invoke(null));
}
@Test
void importFromDifferentPackage() {
rewriteRun(
//language=java
java(
"""
package com.acme.bank;
public class Record {}
"""
),
//language=java
java(
"""
import com.acme.bank.*;
class Foo {
Record r;
}
""",
"""
import com.acme.bank.Record;
class Foo {
Record r;
}
"""
)
);
}
} And then beyond that we'd need to implement the visitor to actually add the unambiguous import that avoids package org.openrewrite.java.migrate.lang;
import lombok.EqualsAndHashCode;
import lombok.Value;
import org.openrewrite.*;
import org.openrewrite.java.JavaIsoVisitor;
import org.openrewrite.java.search.UsesType;
import org.openrewrite.java.tree.J;
@Value
@EqualsAndHashCode(callSuper = false)
public class AvoidConflictingImports extends Recipe {
@Option(displayName = "Import",
description = "The fully qualified name of the class introduced.",
example = "java.lang.Record")
String fullyQualifiedClassName;
@Override
public String getDisplayName() {
return "Avoid conflicting imports";
}
@Override
public String getDescription() {
return "Add explicit imports for classes that might otherwise conflict with the argument FQCN.";
}
@Override
public TreeVisitor<?, ExecutionContext> getVisitor() {
return Preconditions.check(Preconditions.and(
new UsesType<>("*..Record", false),
Preconditions.not(new UsesType<>("java.lang.Record", false))
), new JavaIsoVisitor<ExecutionContext>() {
@Override
public J.CompilationUnit visitCompilationUnit(J.CompilationUnit compilationUnit, ExecutionContext ctx) {
J.CompilationUnit cu = super.visitCompilationUnit(compilationUnit, ctx);
// TODO Enforce addition of import for classes that conflict with java.lang.Record
maybeAddImport("com.acme.bank.Record", false);
return cu;
}
});
}
} |
That's the best TODO for this feature. How do we vote? ;)
|
Had a quick look at what's necessary here, and updated the tests above already. We likely have to make a change here to fix one of the tests, as we right now fail to add an import when the import and class are in the same package, whereas we likely need to disambiguate the import even if in the same package: |
What problem are you trying to solve?
Folks using
com.something.Record
throughimport com.something.*;
might find that thejava.lang.Record
is picked up when they migrate to Java 16+. Same for other classes added to the JDK:What precondition(s) should be checked before applying this recipe?
Using any conflicting classes on older Java versions
Describe the situation before applying the recipe
Describe the situation after applying the recipe
Any additional context
Reported via email, with an example use case in
https://github.com/fmcdevops/medrec/blob/master/src/common/value/com/bea/medrec/value/Record.java
The text was updated successfully, but these errors were encountered: