Skip to content
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

Open
evie-lau opened this issue May 21, 2024 · 4 comments · May be fixed by #4294
Open

Inconsistent insertion order for addMethodDeclaration #4203

evie-lau opened this issue May 21, 2024 · 4 comments · May be fixed by #4294
Labels
bug Something isn't working

Comments

@evie-lau
Copy link
Contributor

evie-lau commented May 21, 2024

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.

@timtebeek
Copy link
Contributor

timtebeek commented May 22, 2024

Hmm; that's unfortunate! Had a quick look; this seems to be the relevant bit of code

public JavaCoordinates addMethodDeclaration(Comparator<J.MethodDeclaration> idealOrdering) {
Comparator<UUID> natural = Comparator.naturalOrder();
return addStatement((org.openrewrite.java.tree.Statement s1, org.openrewrite.java.tree.Statement s2) -> s1 instanceof J.MethodDeclaration && s2 instanceof J.MethodDeclaration ?
idealOrdering.compare((J.MethodDeclaration) s1, (J.MethodDeclaration) s2) :
natural.compare(s1.getId(), s2.getId())
);
}

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?

@timtebeek timtebeek transferred this issue from openrewrite/rewrite-migrate-java May 22, 2024
@timtebeek timtebeek added the bug Something isn't working label May 22, 2024
@evie-lau
Copy link
Contributor Author

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.

@timtebeek
Copy link
Contributor

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.

@knutwannheden
Copy link
Contributor

I think the only thing we can do is for addMethodDeclaration() to somehow only consider method declarations. But I am also a bit unsure about this entire coordinate. The before() and after() seem a lot more predictable. What should addMethodDeclaration() do in case no methods exist?

@Riyazul555 Riyazul555 linked a pull request Jun 29, 2024 that will close this issue
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Backlog
Development

Successfully merging a pull request may close this issue.

3 participants