Test fails only in IntelliJ

[Bananeweizen]

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

Open RefasterTemplateProcessorTest.java, hit the Run button of IntelliJ. On my Windows 10 machine this leads to a failing test.

What did you see instead?

> Difference in expected tree and actual tree.
      Expected node: Line 56 COMPILATION_UNIT->CLASS(UseStringIsEmptyRecipe)->METHOD(getDescription)->BLOCK(non-static)->RETURN->STRING_LITERAL(Second line that should show up in description only.
     May contain " and ' and \" and \\" and \n.
     Or even references to `String`.
     Or unicode �.)
      Actual node: Line 41 COMPILATION_UNIT->CLASS(UseStringIsEmptyRecipe)->METHOD(getDescription)->BLOCK(non-static)->RETURN->STRING_LITERAL(Second line that should show up in description only.
     May contain " and ' and \" and \\" and \n.
     Or even references to `String`.
     Or unicode �.)

The mismatch is in the unicode "bug" character: 🐛 from https://github.com/openrewrite/rewrite-templating/blob/0e4a1440df56537041bbc86294dc77f22758c288/src/test/resources/refaster/UseStringIsEmpty.java#L28. Please note that it is not correctly decoded in both the expected and actual values. Running the same test (in the same git repository) via gradlew command line is fine.

Are you interested in contributing a fix to OpenRewrite?

I use IntelliJ too seldom to really know what I could investigate here, so probably not.

[timtebeek]

Thanks for the report! I suspect this is an issue with how we use com.google.testing.compile:compile-testing; I'd started on a branch that no longer reads files from disk, but instead has the source files as text blocks. That might improve things here too. I've not yet pushed that out given that it's likely to conflict with other running efforts, but figured mention it here as a possible solution.

[Bananeweizen]

Okay, I think I found the culprit. gradle tests also fail if a JDK < 21 is set as JAVA_HOME. My IntelliJ used JDK8 for launching the test, because the gradle config declares compatibility with Java 8. And we all know that in Java 18 the default character set changed. That's why on older JDKs the test fails to decode the UTF-8 encoded input, if running on a platform where UTF-8 was not yet the default before (like Windows). I suspect an upstream bug at https://github.com/google/compile-testing/blob/6493d6f341fd5628e8680b7c2f75e085692c0e9f/src/main/java/com/google/testing/compile/JavaFileObjects.java#L124 (or similar lines of code). You may want to modify that code in your branch, if possible. Besides that, this could probably also be fixed by explicitly setting -Dfile.encoding somewhere in the gradle settings, but I'm not that fit in gradle settings to actually propose a file change. Anybody else with more Gradle knowledge?

[knutwannheden]

Something like this might do it: https://discuss.gradle.org/t/no-possibility-to-set-file-encoding-for-junit-tests-in-gradle-2-13-and-odler/17223/2