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:

1.6
1.6
1.6
1.6
:clean
:compileJava
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?

Sample build file that demonstrates behaviour.

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
:help

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

BUILD SUCCESSFUL

Total time: 4.453 secs
C:\intellij_projects\MDP>

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

C:\intellij_projects\MDP>

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

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
:jar 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

BUILD SUCCESSFUL

Total time: 11.329 secs
C:\TEMP>

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

Regards,
Jens

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

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!

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.