NoGuava Recipe – Summary of the analysis on the Sirius-Desktop codebase

This ticket is not really a bug report, but rather a summary of the tests and fixes I’ve made regarding the NoGuava recipe, based on the Sirius-Desktop codebase.
I started this analysis about two weeks ago. At that time, the version of rewrite-migrate-java I used was v3.19.0. Running the migration resulted in around 437 compilation errors.

After several issues and PRs (thanks to @timtebeek), I now get down to around 179 compilation errors.
Most of these remaining errors come from cases that are not yet handled, including some that are difficult to support because doing so could impact performance (there’s no direct Java equivalent).

To make my analysis easier (and faster), I created a minimal example, minimal-app, containing all the test cases used in the NoGuava recipes, as well as the remaining unhandled cases - with the goal of getting as close as possible to 100% coverage on the Sirius-Desktop codebase. This minimal example may be useful to others as well, so I’m attaching it here: minimal-app.zip.

For the moment, I think I'll leave it at that.

What version of OpenRewrite are you using?

Initially I was using:

• Maven v3.9.5
• Rewrite Maven Plugin v6.21.1
• org.openrewrite.recipe:rewrite-migrate-java v3.19.0

And now, I am using:

• Maven v3.9.5
• Rewrite Maven Plugin v6.23.0
• org.openrewrite.recipe:rewrite-migrate-java v3.21.0

How are you running OpenRewrite?

I used the Maven command line to launch the recipe on the minimal-app sample :

mvn -U org.openrewrite.maven:rewrite-maven-plugin:6.23.0-SNAPSHOT:run \
    -Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-migrate-java:3.21.0-SNAPSHOT \
    -Drewrite.activeRecipes=org.openrewrite.java.migrate.guava.NoGuava \
    -Drewrite.exportDatatables=true \
    -Dmaven.repo.local=./.repositoryMaven

You may need to update the versions depending on the current SNAPSHOT version.

What is the smallest, simplest way to reproduce the problem?

This minimal example, minimal-app, includes two classes:

• GuavaConversionSamples_AllOK: Contains all the handled cases and helps ensure there are no regressions overall.
• GuavaConversionSamples: Contains the same cases as above, plus all those still producing errors.

What did you expect to see?

The expected outcome and the verification steps to perform after the migration are detailed in the Javadoc of each class.

Start with the attached minimal-app sample, especially GuavaConversionSamples_AllOK and GuavaConversionSamples, and read the Javadoc in each class for the stated verification steps. Run the documented Maven command against the NoGuava recipe and compare handled and remaining cases; the issue does not define a concrete change or completion criterion.