Gradle seems to read .gradle files using UTF-8. However my build script was edited with ISO-8859-1 charset. So, I want to tell Gradle to read the build.gradle using ISO-8859-1 instead of UTF-8. How can I do that?
I already tried to add the following to gradle.properties, with no luck: systemProp.file.encoding=ISO-8859-1
gradlew -Dfile.encoding=ISO-8859-1 does not work either (and in any case I would prefer to put this information within my build script).
The problem I see is that if I put the following in my build script, edited with ISO-8859-1 charset: logger.lifecycle (‘àèìòù’) Gradle outputs the accented letters as corrupted.
It uses the JVMs platform encoding. This is controlled by the value of the ‘file.encoding’ system property when the JVM starts. It’s immutable once the JVM starts.
The reason the approaches you tried didn’t work is that they are changing the value too late.
if you have ‘-Dfile.encoding=ISO-8859-1’ in the ‘GRADLE_OPTS’ env var it should work.
It’s a bug that the ‘systemProp.file.encoding’ in ‘gradle.properties’ doesn’t work.
Thanks for the quick reply. Unfortunately, GRADLE_OPTS=-Dfile.encoding=ISO-8859-1 does not work either, I still get a corrupted output.
By the way, the file.encoding system property is not a documented property required by the Java platform specification, but rather an implementation detail. So, having a “standard/supported” way for Gradle to specify such an information would be appreciated. The gradle.properties file would be perfect for me.
For “standard way” I mean “standard” for Gradle, not for the JVM. I mean, if the Gradle API supports a property (say “buildscript.encoding” or such) in gradle.properties to specify the encoding to use to read the .gradle files, which defaults to “UTF-8” if not specified, then the user would have a “standard” way to specify this information to Gradle without guessing the use of the file.encoding system property (which is rather a JVM implementation detail).
Anyway, once we have determined that neither systemProp.file.encoding in gradle.properties nor GRADLE_OPTS=-D… works, is there a way to open a bug? (now JIRA says the forum is the place to file bugs…).
We don’t really know what the bug is yet to raise. I can’t reproduce the problem and this hasn’t been reported by others. If it were such a general problem I’d expect others to have hit it by now.
Gradle reads and compiles the script with the platform encoding, so something else is going on. We just haven’t figured out what yet.
From my experience, ‘GRADLE_OPTS’ works fine, and I’ve just verified it for your case. Note that you need to configure your shell to use ISO-8859-1 as well.
I can simply reproduce in this way under Windows 7: - create a folder (say test-gradle) - create a build.gradle in that folder - this is the content of the build.gradle file:
task myYask() {
logger.lifecycle (‘àèìòù’) }
Please note you should use a standard Windows editor to edit that file. Windows default charset is cp1252, which is a superset of ISO-8859-1.
Just run “gradle” on that folder.
This is the output for me:
ÓÞý‗¨ :help (etc.)
I’m using the standard Windows prompt, so the shell must be using the default encoding for Windows.
Reproduced with Gradle 1.0, 1.4, 1.5, 1.6. Invoking: set GRADLE_OPTS=-Dfile.encoding=ISO-8859-1 or either set GRADLE_OPTS=-Dfile.encoding=cp1252 does not help.
As I said, my “shell” is the Windows command prompt.
Well, you’ll never stop to learn… I was almost sure the Windows command prompt used the cp1252 character set by default, since this is the default o.s. file encoding… however, this is not true!
It turns out that the default character set used by the Windows command prompt is cp850, which explains why I see garbage. In fact, also: type build.gradle shows the garbage in the string argument of logger.lifecycle(…).
But this is not the whole story. If you type the command “chcp” you’ll see that the default charset is cp850. But even if you change it to cp1252 using “chcp 1252”, the “type build.gradle” command or the “gradlew” launching will still produce garbage. Looking at the following: http://stackoverflow.com/questions/1259084/what-encoding-code-page-is-cmd-exe-using I’ve discovered that to make the console react as it should to the change of the charset, you must configure the Windows command prompt to use the Lucida Console or Consolas fonts instead of the “raster fonts” (which is the default!!!).
So, to sum it up, to make it work correctly you have to: - change the options of the Windows command prompt to use the Lucida Console or Consolas font - type "chcp " to set the correct codepage (1252 in my example) - ensure that the build script is edited with the correct encoding - ensure that Gradle is using the correct encoding to load the script, using GRADLE_OPTS to set the file.encoding system property if needed
Maybe this can be useful to you to know, too. Thanks for the hint to discover this!
I understand that gradle takes whatever default encoding the JVM derives from the shell. I wonder that this has not been a problem yet, because it means gradle build files are not portable per se. If i want to build, say, gradle itself, how do i know which encoding to set beforehand? If i build on Windows via cmd, it will use Cp850, on Unix it might use UTF-8 for me and ISO-8859-1 for my colleague. How do CI systems (Travis, Jenkins) cope with this?
Both ant and maven use xml, which carries the encoding along the content of the file. Shouldn’t gradle build files per definition be something like UTF-8? There’s lots of rants against using ISO-8859-1 encoding for all Java property files, but at least you know what you’re talking about…
