-
Notifications
You must be signed in to change notification settings - Fork 465
Add @InlineMe
and InlineMethodCalls
recipe to replace annotated methods
#5953
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
Conversation
.contextSensitive() | ||
.imports(values.getImports().toArray(new String[0])) | ||
.staticImports(values.getStaticImports().toArray(new String[0])) | ||
.javaParser(JavaParser.fromJavaVersion().classpath(JavaParser.runtimeClasspath())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This runtimeClasspath
is the only part I'm not quite pleased with, as what's on the runtime classpath might differ in certain environments. Still I wouldn't immediately know of a good alternative here, and we've already seen the recipe work in practice on some projects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think for now runtimeClasspath()
is as good as you're going to get
} | ||
List<String> parameterNames = methodType.getParameterNames(); | ||
if (!parameterNames.isEmpty() && "arg0".equals(parameterNames.get(0))) { | ||
return null; // We need `-parameters` before we're able to substitute parameters in the template |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels like something we could always enable in JavaParser
if it isn't by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it's here mostly as a safeguard; it should be set in each of the Java parsers we have:
rewrite/rewrite-java-21/src/main/java/org/openrewrite/java/isolated/ReloadableJava21Parser.java
Line 112 in 380c942
Options.instance(context).put("-parameters", "true"); |
What's changed?
Add an annotation and associated recipe, which supports any recipe with the same structure: our own, Google's or a library specific one, much like
@Nullable
can come from a variety of librariesWhat's your motivation?
Allow folks to easily mark methods for replacement with an argument template. We have these use cases internally for our libraries any moment we expand a constructor with a new nullable argument, or when deprecating a method with a clear one to one replacement using (some of) the same arguments.
It's already used in libraries like Guava, where we can now do such replacements just from having the library on the classpath.
Anything in particular you'd like reviewers to focus on?
Would we want to support and promote this going forward?
Have you considered any alternatives or workarounds?
@InlineMe
I've considered@ReplaceWith
, to more clearly state that it's not just for inlining. We can optionally support both.Any additional context
@InlineMe
annotation replacements rewrite-migrate-java#788@Deprecated
: Recipe to apply Kotlin's@Deprecated(replaceWith=...)
suggestions #5929