The subproject baseService compiles cleanly only with a JDK’s compliance of 1.8. With a 1.7 compliance, one gets the errors below
Description Resource Path Location Type
The method addAll(Collection<? extends T>) in the type List<T> is not applicable for the arguments (List<Object>) CollectionUtils.java /baseServices/src/main/java/org/gradle/util line 240 Java Problem
Description Resource Path Location Type
Type mismatch: cannot convert from Pair<capture#2-of ? extends T,R> to Pair<T,R> Pair.java /baseServices/src/main/java/org/gradle/internal line 68 Java Problem
gradlew --version
Gradle 3.2-20160930000021+0000
Build time: 2016-09-30 00:00:21 UTC
Revision: 6e814ee56c8cfa40699afd79220aa4e0a4a7d618
Groovy: 2.4.7
Ant: Apache Ant™ version 1.9.6 compiled on June 29 2015
JVM: 1.8.0_102 (Oracle Corporation 25.102-b14)
OS: Windows 10 10.0 amd64
We do build Gradle with JDK 7 on our CI and it works.
Your output of gradlew --version shows that you use JDK 8.
I just ran it using JDK 7 and it succeeded.
Actually, baseService is built with sourceCompatibility set to 1.5.
Well, 1.6 when built using Java 9 as it does not support 1.5.
See https://github.com/gradle/gradle/blob/master/subprojects/base-services/base-services.gradle
Any chance you can give more details about what you’re doing, maybe it’s an IDE issue?
You are right, I did not give the full context, sorry. Here the point
The JDK version 8 displayed is the one used when building Gradle from a DOS window, where JAVA_HOME points to C:\Program Files\Java\jdk1.8.0_102.
But when under Eclipse, each project generated by the gradle’s eclipse task gets its own compliance setup in a file named subprojects\base-services.settings\org.eclipse.jdt.core.prefs where the compliance level is defined as below
Since the gradle eclipse plugin is generating the Eclipse’s .project and .classpath file, I was thinking it was also generating the .setting files. Obviously, I was wrong and I have no idea why Eclipse generates such 1.5 compliance level while it is started with a 1.8 JDK.
Ok, so the baseService project in the Gradle Build Tool sources uses sourceCompatibility = '1.5' so the eclipse task of the Gradle Build Tool sources generates Eclipse files with both compliance and sources to 1.5. That sounds perfectly normal.
We don’t use Eclipse much to work on Gradle itself.
The original error you reported is displayed inside Eclipse, correct?
The method addAll(Collection<? extends T>) in the type List is not applicable for the arguments (List) CollectionUtils.java /baseServices/src/main/java/org/gradle/util line 240
Type mismatch: cannot convert from Pair<capture#2-of ? extends T,R> to Pair<T,R> Pair.java /baseServices/src/main/java/org/gradle/internal line 68
It looks like an Eclipse compiler bug or something like that.
Ok, so the baseService project in the Gradle Build Tool sources uses sourceCompatibility = ‘1.5’ so the eclipse task of the Gradle Build Tool sources generates Eclipse files with both compliance and sources to 1.5. That sounds perfectly normal.
Sorry but as soon as there are @overriden annotation in the source code, the compliance level should be at least 1.6. Moreover, Gradle itself is requesting a JDK 1.7 as show below
:\Users\fandre\Documents\git\gradle-mc>gradlew assemble
FAILURE: Build failed with an exception.
What went wrong:
Gradle 3.2-20160930000021+0000 requires Java 7 or later to run. You are currently using Java 6.
Thus I would expect to see the compliance level set by Gradle if any at least at the 1.7 level for Eclipse
It’s a bit more complicated The wrapper still needs to start on Java 5 (to give the user a good error message). Compiler daemons and test execution still need to run on Java 6.
I have changed the compliance level for Eclipse to 1.7. Still, Eclipse can’t handle some of our code because its Groovy integration is really bad. I suggest using IntelliJ.
I have changed the compliance level for Eclipse to 1.7. Still, Eclipse
can’t handle some of our code because its Groovy integration is really
bad. I suggest using IntelliJ.
Using compliance level to 1.8 fixes all errors in the java code but it remains errors in the groovy one (specifically on src/test/**)
I have other dependent projects that are shared with my colleagues which are using Eclipse, so IntelliJ is not really an option I can pursue. Sorry.