Created attachment 162435 [details]
Screenshot of error
Observed in a few cases, but for example:
Reproducible from dev sources (16f9bbc04752):
ant clean build-nozip tryme -Dcluster.config=java -Dtryme.arg.nbopen='--open …/jenkinsci/workflow-support-plugin …/jenkinsci/workflow-support-plugin/src/main/java/org/jenkinsci/plugins/workflow/support/concurrent/Futures.java:243'
The project is compilable using JDK 8:
JAVA_HOME=…/jdk1.8.0_101 mvn -f …/jenkinsci/workflow-support-plugin -DskipTests clean install
I tried in JDK 9 (EA 139) but got some unrelated error, presumably due to modules:
[ERROR] java.nio.file.NoSuchFileException: …/jenkinsci/workflow-support-plugin/target/classes/META-INF/annotations/org.kohsuke.accmod.Restricted
[ERROR] java.nio.file.NoSuchFileException: …/jenkinsci/workflow-support-plugin/target/classes/META-INF/annotations/hudson.Extension
Tried to bisect (starting from 34c73be6b85c as known-good) but I am not sure if I screwed it up because in some IDE versions, an error badge appears on the project and on the editor tab while no error mark appears inside the editor in the gutter or on the line, and I get
WARNING [org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges]: Incorrect error badges detected, file=…/jenkinsci/workflow-support-plugin/src/main/java/org/jenkinsci/plugins/workflow/support/concurrent/Futures.java.
WARNING [org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges]: Going to recompute root=…/jenkinsci/workflow-support-plugin/src/main/java, files in error=.
At any rate, no big surprise at the result:
The first bad revision is:
user: Tomas Zezula <firstname.lastname@example.org>
date: Sun Nov 29 10:53:59 2015 +0100
summary: Merging default -> jdk9.
As usual with these things, it is possible that the JDK 9 javac is simply being stricter about some corner case in the language that earlier releases were more tolerant of, but if so I would like some sort of confirmation from the JDK team that treating this source file as erroneous is deliberate and the behavior in JDK 9 FCS will be the same.
Yes, there is a change in JDK9's generics resolution. Could you please try to change your project's source level from 1.7 to 1.8 ? It should help.
to the POM’s `<properties>` section does cause the error to disappear. I am not about to do that, because this module must be usable on Java 7 runtimes.
Again, to clarify, the module does compile without error using Maven on JDK 8, where the POM default passes `-source 7 -target 7`.
So did JDK 9 include a deliberate change in generics resolution when applied to Java 7 sources?
I think this is https://bugs.openjdk.java.net/browse/JDK-8075793. If the evaluation there is correct, there is no bug in NetBeans, but it is something that should be mentioned in release notes.
Can you please update the bundled javac to a version which includes http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/49170d831308? That would effectively fix the bug.