-
Notifications
You must be signed in to change notification settings - Fork 288
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
Inconsistent insertion order for addMethodDeclaration
#4203
Comments
Hmm; that's unfortunate! Had a quick look; this seems to be the relevant bit of code rewrite/rewrite-java/src/main/java/org/openrewrite/java/tree/CoordinateBuilder.java Lines 111 to 117 in 8779514
That seems to work ok when exclusively comparing methods to methods, but the fallback to UUID comparison for anything else is a bit suspicious to me. What are your thoughts there? |
For ordering consistency, it doesn't seem like the UUID is a good comparison. But after briefly looking at some of the options for Statements, it seems hard to find anything to compare without first casting it to another J type. |
Can only agree; no immediate better solution comes to mind, especially if we want to be somewhat mindful of performance, meaning printing each element as we compare is likely out. I'd briefly looked if there's any widely used convention for how to order types of elements compared to each other, similar to how an IDE might group elements. Perhaps we could compare dissimilar LST types by class simple name? That could help to then only compare methods against methods in a stable order. |
I think the only thing we can do is for |
When using
.addMethodDeclaration(Comparator.comparing(J.MethodDeclaration::getSimpleName))
, it does not seem to consistently place the new MethodDeclaration in the same place, resulting in unit tests intermittently failing.Example in a previous PR, where I resorted to switching to use
.firstStatement
to pass unit tests consistently.The text was updated successfully, but these errors were encountered: