Module baseService compiles only with JDK 1.8 compliance

Hi

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

Hi,

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

eclipse.preferences.version=1
org.eclipse.jdt.core.circularClasspath=warning
org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
org.eclipse.jdt.core.compiler.codegen.methodParameters=do not generate
org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5
org.eclipse.jdt.core.compiler.codegen.unusedLocal=preserve
org.eclipse.jdt.core.compiler.compliance=1.5
org.eclipse.jdt.core.compiler.debug.lineNumber=generate
org.eclipse.jdt.core.compiler.debug.localVariable=generate
org.eclipse.jdt.core.compiler.debug.sourceFile=generate
org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
org.eclipse.jdt.core.compiler.source=1.5

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

That’s not the case in baseServices.

It’s a bit more complicated :wink: 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.

May be I am wrong but I found 243 @Override annotations in the baseService subproject

[FrancisANDRE@idefix gradle-vs2015 ]$find subprojects/base-services/src/main/java -type f -name "*.java" | xargs grep Override | wc -l
243

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.

I don’t quite understand. What dependent projects? I just meant use IntelliJ to work on Gradle. You can still use Eclipse for all your other projects.

Stephan

[st_oehme] st_oehme https://discuss.gradle.org/users/st_oehme
Stefan Oehme https://discuss.gradle.org/users/st_oehme Core Dev
October 6

zosrothko:

I have other dependent projects that are shared with my colleagues
which are using Eclipse

I don’t quite understand. What dependent projects? Are you forking Gradle?

It was a politicaly correct answer… I do not want to learn another IDE
for Java… That’s too much effort…