Add encoding to JavaPluginExtension

[JojOatXGME]

Expected Behavior

You can specify the encoding of your source files in the java extension.

java {
    sourceCompatibility = JavaVersion.VERSION_11
    encoding = 'UTF-8'
}

Current Behavior

You have to specify the encoding for every task.

java {
    sourceCompatibility = JavaVersion.VERSION_11
}
tasks.withType(JavaCompile) {
    options.encoding = 'UTF-8'
}
tasks.withType(Javadoc) {
    options.encoding = 'UTF-8'
}

Context

The default encoding depends on the platform. Some time ago, I had the issue that when I build my project on the “wrong” platform (Windows), some characters were displayed incorrectly in the application. Another time, I actually got an compile error. To make the build consitent on different platforms, I always specify the encoding as shown above. Since I consider consistent builds as quite important, specifying the encoding for all relevant tasks should be easier.

PS: I would also consider useing UTF-8 as default instead of making it platform dependent. This might also fix parts of #9091. However, that is another topic.

[lptr]

Having an explicit default like UTF-8 would be nice for more consistent caching. Introducing a default would break some builds, though. And I wonder if it would work for countries like China where encodings like GBK are typical.

[vlsi]

JEP draft: Use UTF-8 as default Charset

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[JojOatXGME]

I still think this is an important feature since essentially every Java project must specify the encoding. Not specifying the encoding might lead to problems if the project is built on other platforms. If JEP 400 is accepted, the feature might be less important but is still reasonable.

Is it worth preparing a pull request for this topic? I guess I could try to prepare a pull request, although it may take some time before I start with it. The topic doesn't look too complicated.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[vlsi]

The issue is still relevant

[JojOatXGME]

I just tried to use OpenJDK 20 on a newly created project in the hope that the issue would be resolved since JEP 400 is implemented as of JDK 18. Unfortunately, it looks like IntelliJ (or Gradles tool integration?) is adding -Dfile.encoding=windows-1252 when launching the daemon.

FYI, I noticed that the documentation suggests specifying the encoding in the gradle.properties and it seems to work. I just wanted to mention it since it wasn't mentioned here before. However, note that adding this option will also change the amount of memory available during the build. If you want to only change the encoding, you would have to repeat the defaults.

org.gradle.jvmargs=-Xms256m -Xmx512m -XX:MaxMetaspaceSize=384m -Dfile.encoding=UTF-8

BTW, the documentation for Configuring JVM memory also casually specifies the encoding in their examples without any explanation, which is a bit odd in my opinion. But I mean, I think it is generally odd that Gradle does not default to consistent builds and only makes them possible over such "hidden" configurations.