[GRADLE-2183] compileJava ignores project.sourceCompatibility Created: 20/Mar/12  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-9
Fix Version/s: None

Type: Bug
Reporter: Jens Hausherr Assignee: Unassigned
Resolution: Won't Fix Votes: 1

Attachments: File build-m9.gradle     File gradle-2183.gradle    


The documentation of the compile task states that the setting of both sourceCompatibility and targetCompatibility default to project.sourceCompatibility and project.targetCompatibility respectively.

With a project configured to use 1.6 as both source and target compatibility I added the following to my build.gradle to check:


{ println project.sourceCompatibility println project.targetCompatibility println sourceCompatibility println targetCompatibility }

which produces:


Adding the following snippet to the build script yields the expected behaviour:


{ sourceCompatibility = project.sourceCompatibility targetCompatibility = project.targetCompatibility }

compileTestJava { sourceCompatibility = project.sourceCompatibility targetCompatibility = project.targetCompatibility }

This behaviour is either a bug, as plugins should IMHO honour the projects settings or the documentation of the compile task needs clarification concerning the default settings of the compile task.

Comment by René Gröschke (Inactive) [ 23/Mar/12 ]

Hello Jens,
I tried to reproduce the problem with the following snippet:

apply plugin:'java'

targetCompatibility = 1.6
sourceCompatibility = 1.6

compileJava { 
	println project.sourceCompatibility 
	println project.targetCompatibility 
	println sourceCompatibility 
	println targetCompatibility 

but that works correctly on my machine (gradle m9 + java7) and results in the expected output:

warning: [options] bootstrap class path not set in conjunction with -source 1.6
1 warning

Can you provide a gradle build file snippet (including the configuration of your sourc- + targetCompatibility) to reproduce your problem?

Comment by Jens Hausherr [ 23/Mar/12 ]

Sample build file that demonstrates behaviour.

Comment by Jens Hausherr [ 23/Mar/12 ]

I think I found the problem. apply plugin:'java' seems to set the values sourceCompatibility and targetCompatibility to their initial default values. (The attached build script should demonstrate this.)

The difference is that I set the properties in the build script before applying the java plugin. So IMHO it boils down to whether a plugin should check for properties already set or whether it shopuld be clear that applying a plugin erases any properties that it provides if already set.

Here is the output I get:

C:\intellij_projects\MDP>gradle -b gradle-2183.gradle
project.sourceCompatibility: 1.6
project.targetCompatibility: 1.6
sourceCompatibility: 1.6
targetCompatibility: 1.6
sourceCompatibility (compileJava): 1.7
targetCompatibility (compileJava): 1.7

Welcome to Gradle 1.0-milestone-9.

To run a build, run gradle <task> ...

To see a list of available tasks, run gradle tasks

To see a list of command-line options, run gradle --help


Total time: 4.453 secs

Here is the ouput of gradle -v:

C:\intellij_projects\MDP>gradle -v

Gradle 1.0-milestone-9

Gradle build time: Dienstag, 13. März 2012 16:10 Uhr UTC
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.8.2 compiled on December 20 2010
Ivy: 2.2.0
JVM: 1.7.0_03 (Oracle Corporation 22.1-b02)
OS: Windows XP 5.1 x86

Comment by René Gröschke (Inactive) [ 23/Mar/12 ]

Hello Jens,
as you already pointed out, the reason for this unexpected behavior is, that you define targetCompatibility and sourceCompatibility before applying the java plugin. With your snippet above the "apply plugin:'java' you introduce two NEW variables to the build script, which have the same name as the properties "targetCompatibility" and "sourceCompatibility" of the java base plugin, but they are completely unrelated. The new "ext" syntax you already use for gradle >= m9 addresses this problem of dynamic property creation. I suggest you to move the lines

/* define the valid syntax level for source files */
sourceCompatibility = JavaVersion.VERSION_1_6
/* define binary compatiblity version */
targetCompatibility = JavaVersion.VERSION_1_6

directly below the line – apply plugin:'java' --. That should solve your issue. For more background informations about this kind of problem in gradle build scripts, you should have a look at an announcement created by Luke in gradle forum: http://forums.gradle.org/gradle/topics/6caj90zrfqr0l

Comment by Jens Hausherr [ 26/Mar/12 ]

Hello René,

maybe I fused by brain, but it still does not work for me. Please have a look at the attached build file. Maybe you can tell me where I am wrong. Here is what I did:

  1. I apply the java plugin in the first line of the build script
  2. I then set source/target compatibility via the new ext way.
  3. I added some before/after printlns to output the setting of the source/targetCompatibility properties for both project and compileJava target.

And here is what I get:

C:\TEMP>gradle build -b build-m9.gradle
Proj Target: 1.6
Proj Source: 1.6
Compile Target: 1.7
Compile Source: 1.7
Compile target (after explicit set): 1.6
Compile source (after explicit set): 1.6
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:assemble UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build UP-TO-DATE


Total time: 11.329 secs

I am still puzzled. It should work now, shouldn't it?


Comment by Adam Murdoch [ 08/May/12 ]

You shouldn't be using the ext block to set the compatibility levels. Have a look at this sample: http://gradle.org/docs/current/userguide/tutorial_java_projects.html#N104C1

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 12:14:58 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.