Why sourceCompatibility doesn't always work


(Mark Thornton) #1

In a multi module project your master build.gradle might look like this:

subprojects {

project.sourceCompatibility = 1.6 }

the java subprojects then have a build.gradle like this:

apply plugin: ‘java’

However when you run with a 1.7 jdk the class files will have version 51 and not the expected 50. To make it work you must either move the setting of source compatibility to each of those subprojects, or move the apply plugin: ‘java’ to the master. Is the second option legitimate if some subprojects contain no java?

What is the best way to set java plugin options when not all subprojects are java?

This query on stackoverflow: http://stackoverflow.com/questions/21028438/gradle-sourcecompatibility-1-6-does-not-seem-to-create-1-6-byte-code

I think results from this issue.


(Peter Niederwieser) #2

‘sourceCompatibility’ is added by the Java (base) plugin. If you set it before applying that plugin, you are instead setting a dynamic property with the same name, which won’t have the desired effect. Right now, this will give a warning; in 2.0, it will give an error.

It’s common to do ‘subprojects { apply plugin: “java”; /* configure sth. related to the Java plugin */ }’. You can also configure selected subprojects from a parent script (see Gradle User Guide for details). Another option is to have a ‘gradle/javaProject.gradle’ script, which each Java project applies with ‘apply from: “$rootDir/gradle/javaProject.gradle”’. (This is perhaps the clearest option, and also the most future-proof one.) Yet another option is to configure just the projects that will eventually have the Java plugin applied from the parent project: ‘subprojects { plugins.withType(JavaPlugin) { … } }’.


(Mark Thornton) #3

Right except that the warning might lead you to try

ext {

sourceCompatibility = 1.6 }

which eliminates the warning, but doesn’t have the right effect. I think some extra examples in the user guide would be helpful.