[GRADLE-1010] Add project setting (similar to sourceCompatibility/targetCompatibility) for source encoding and have Compile task use it Created: 29/Jun/10  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: Steve Ebersole Assignee: Unassigned
Resolution: Won't Fix Votes: 12


Currently in order to specify encoding to use for source compilation, user would need to configure each Compile task in their build to add a compiler argument for encoding. Would be much nicer to allow for this on the project itself as is done for sourceCompatibility and targetCompatibility

Comment by Paulo Silveira [ 08/Aug/10 ]

Steve, how are you doing this?

compileJava {
options.compilerArgs = ['-encoding utf8']

will complain about the -encoding option, although it is a valid javac one.

Comment by Paulo Silveira [ 08/Aug/10 ]

I ve managed to do it with compiler.options.encoding, although there is no documented encoding attribute at CompilerOptions class.

Comment by Hans Dockter [ 09/Aug/10 ]

We plan to provide a full Gradle DSL documentation (no Javadoc/Groovydoc) for 1.0.

Comment by Jean-Baptiste Nizet [ 05/Apr/12 ]

If this improvement is implemented, it would also be nice to make the eclipse and other IDE plugins generate the appropriate configuration file, so that Java source files created in the IDE have the appropriate encoding. At the moment, I hacked the eclipseJdt task to do that:

eclipseJdt << {
    File f = file('.settings/org.eclipse.core.resources.prefs')
Comment by Marcel Overdijk [ 11/Dec/12 ]

I would expect something like

sourceEncoding = "UTF-8"

Extended example from 7.2.3. Customising the project:

sourceCompatibility = 1.5
sourceEncoding = "UTF-8"
version = '1.0'
jar {
    manifest {
        attributes 'Implementation-Title': 'Gradle Quickstart', 'Implementation-Version': version
Comment by Luke Daley [ 23/Jan/13 ]

We are moving away from such global properties, as it gets confusing in a more complicated context.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 11:44:36 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.