SBT Launcher on Windows and Java 9+ fails on non-ASCII user dirs

[JD557]

steps

• Have a user dir with non-ASCII characters (e.g. C:/Users/João)
• Launch sbt (with java 9 or higher)

problem

• The launcher presents a "The directory or file cannot be created." and fails to load "rt.jar"

expectation

• This shouldn't fail

notes

The error comes from the way batch files interact with UTF-8 and files.

From a quick investigation, the problem is in the following lines:

if /I !JAVA_VERSION! GEQ 9 (
  "!_JAVACMD!" !_JAVA_OPTS! !_SBT_OPTS! -jar "!sbt_jar!" --rt-ext-dir > "%TEMP%.\rtext.txt"
  set /p java9_ext= < "%TEMP%.\rtext.txt"
  set "java9_rt=!java9_ext!\rt.jar"
  if not exist "!java9_rt!" (
    mkdir "!java9_ext!"
    "!_JAVACMD!" !_JAVA_OPTS! !_SBT_OPTS! -jar "!sbt_jar!" --export-rt "!java9_rt!"
  )
  set _JAVA_OPTS=!_JAVA_OPTS! -Dscala.ext.dirs="!java9_ext!"
)

• %TEMP%.\rtext.txt is, in my case, correctly pointing to C:\Users\JOO~1\AppData\Local\Temp.\rtext.txt"
• "!_JAVACMD!" !_JAVA_OPTS! !_SBT_OPTS! -jar "!sbt_jar!" --rt-ext-dir > "%TEMP%.\rtext.txt" writes the directory to rtext.txt as "C:\Users\João\.sbt\1.0\java9-rt-ext-eclipse_adoptium_19_0_2" encoded as latin1[dos], with the ã encoded as E3
• set /p java9_ext= < "%TEMP%.\rtext.txt" loads the data (echoing the variable on my machine prints "C:\Users\JoÒo\.sbt\1.0\java9-rt-ext-eclipse_adoptium_19_0_2, but that might be my terminal configuration)
• It enters the if not exist "!java9_rt!", as it cannot find the file
• mkdir "!java9_ext!" fails, as the pah is invalid

Note that everything seems to work if I force set java9_ext= < "C:\Users\JOO~1\.sbt\1.0\java9-rt-ext-eclipse_adoptium_19_0_2".
I tried other encodings, but was unsuccessful.

[SethTisue]

nice catch

[JD557]

I couldn't fix this, but I also can't stand Java 8 anymore, so currently as a workaround I'm setting JAVA_OPTS=-Duser.home=C:/roothome.

While technically I could have used SBT_OPTS, that does not work on projects with a .sbtopts file.

For scala-cli, this requires one to set scala-cli config java.properties user.home=C:\roothome

Hopefully this workaround can help the next person with the same problem.