Add @InlineMe and InlineMethodCalls recipe to replace annotated methods#5953
Merged
Add @InlineMe and InlineMethodCalls recipe to replace annotated methods#5953
@InlineMe and InlineMethodCalls recipe to replace annotated methods#5953Conversation
timtebeek
commented
Aug 22, 2025
| .contextSensitive() | ||
| .imports(values.getImports().toArray(new String[0])) | ||
| .staticImports(values.getStaticImports().toArray(new String[0])) | ||
| .javaParser(JavaParser.fromJavaVersion().classpath(JavaParser.runtimeClasspath())) |
Member
Author
There was a problem hiding this comment.
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.
Member
There was a problem hiding this comment.
I think for now runtimeClasspath() is as good as you're going to get
sambsnyd
approved these changes
Aug 26, 2025
| } | ||
| 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 |
Member
There was a problem hiding this comment.
This feels like something we could always enable in JavaParser if it isn't by default
Member
Author
There was a problem hiding this comment.
Yes it's here mostly as a safeguard; it should be set in each of the Java parsers we have:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
@Nullablecan 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?
@InlineMeI've considered@ReplaceWith, to more clearly state that it's not just for inlining. We can optionally support both.Any additional context
@InlineMeannotation replacements rewrite-migrate-java#788@Deprecated: Recipe to apply Kotlin's@Deprecated(replaceWith=...)suggestions #5929