Java 11 support

[blindpirate]

Java 11 would be a LTS (long time support) version. For now, it's still a bit earlier to invest our time into it, since it's still not stable and lack of ecosystem. Some issues I've identified include:

• ASM throws IllegalArgumentException upon Java 11 bytecode.
• Scala doesn't support it: object java.lang.Object in compiler mirror not found.
• A bug which is already submitted to Oracle: File.getAbsolutePath() isn't affected by System.setProperty("user.dir", "") and daemon needs correct behavior to set environment.

        System.out.println(new java.io.File("a").getAbsolutePath());
        System.setProperty("user.dir", "/User/zhb");
        System.out.println(new java.io.File("a").getAbsolutePath());

has different behavior on Java 10 and Java 11.

This is not a bug. The "user.dir" property should never be changed in a running VM.

according to JDK team: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8202127

In #2159 , the environment manipulation was disabled for Java 9+. At that point, JDK team promised to disable reflection access in Java 9 - which didn't happen eventually. On Java 9/10/11, illegal reflection access is actually allowed with an warning. This means that we can use reflection to set environment variable as before - and the warning can be suppressed by putting Gradle jars on --module-path then adding --add-opens java.base/java.util=<GRADLE>. However, this doesn't mean we should - we shouldn't keep using this dirty hack to set environment since the first day of Gradle. We need another discussion on how to solve this issue.

[thc202]

For the record, the bug report is:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8202127
and was resolved as "not an issue".

[marcphilipp]

A bug which is already submitted to Oracle

@blindpirate Do we have a link to that bug report?

[blindpirate]

@marcphilipp I updated my content.

[marcphilipp]

Thanks! So, does this mean we can still change environment variables using a reflection (causing a warning) but we know of at least one place were those changes are not taken into account anymore (converting File instances from relative path to absolute path). If so, at least for a changed user.dir, we should not reuse the daemon when run on Java >= 10, right?

[blindpirate]

@marcphilipp Exactly.

[ijuma]

Java 11 entered ramp-down mode and it's important to start testing against it to ensure bugs are fixed before the release. I tried to build Kafka (which uses Gradle) with Java 11 and ran into this issue. Is there a workaround?

[blindpirate]

@ijuma There're 3 issues listed, which one do you mean? For the first one, we've already upgrade to ASM 6.2 in #5802, you can either use a nighty http://services.gradle.org/distributions-snapshots/ or keep using targetCompatibility=10.

For the issue 2/3, --no-daemon should always work.

[marcphilipp]

@ijuma Please note that the latest 11-ea build (20) has a bug that prevents Gradle from downloading anything using HTTPS (see #5850 for details).

[ijuma]

Thanks for the helpful responses. Will try with no-daemon once the next JDK 11 build is out.

[ijuma]

Btw, even with --no-daemon, it seems like some plugins break when Java 11 and relative paths are used. Checkstyle is an example:

Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException: Unable to find: checkstyle/suppressions.xml
at com.puppycrawl.tools.checkstyle.filters.SuppressionsLoader.getSuppressionLoader(SuppressionsLoader.java:263)

[alpar-t]

@blindpirate was there anything decided w.r.t. env vars ? This is affecting us in elastic/elasticsearch#31399 where we require JAVA_HOME to be set.
Once a daemon is started, setting the env var will have no effect.
It would seem to be that the correct behavior would be to start a new daemon in this case. I don't really understand why it was decided to only show a warning in the logs.

[blindpirate]

@atorok We're doing this right now. A new daemon should be used in this scenario.

[oehme]

I don't think starting a new daemon is the right way here. It's a last-ditch option, but environment variables change very frequently and starting a new daemon every time would be catastrophic for performance. We should create a document with a couple of alternative solutions before diving into implementation for that.

[alpar-t]

@oehme maybe at least provide the ability for the build script to say which are the env vars that matter ? Or provide an option to configure if a new daemon is started or not, so build script that don't need env vars can benefit from performance, for the ones that do need them performance won't matter as functionality will be broken in a confusing way, i.m.h.o. that tops performance.

[oehme]

You're assuming there are no better options, like:

• make it work again (supress illegal access warning)
• provide something like StartParameter#getEnv
• provide a BuildOption API which also maps to environment variables

[oehme]

Here's the latest list of failures: https://builds.gradle.org/viewLog.html?buildId=15723921&tab=queuedBuildOverviewTab

[magJ]

Java 11 is now generally available.

[marcphilipp]

After the upgrade to Groovy 2.5.2, compilation of build scripts now fails with error messages like this:

FAILURE: Build failed with an exception.

* Where:
Build file '/home/tcagent1/agent/work/668602365d1521fc/subprojects/logging/build/tmp/test files/unknown-test-class/tn43e/buildSrc/build.gradle'

* What went wrong:
Could not compile build file '/home/tcagent1/agent/work/668602365d1521fc/subprojects/logging/build/tmp/test files/unknown-test-class/tn43e/buildSrc/build.gradle'.
> startup failed:
  General error during semantic analysis: java.lang.UnsupportedOperationException
  
  java.lang.UnsupportedOperationException
  	at groovyjarjarasm.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
  	at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:651)
  	at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:391)
  	at org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:83)
  	at org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
  	at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)
  	at org.codehaus.groovy.control.ClassNodeResolver.findClassNode(ClassNodeResolver.java:172)
  	at org.codehaus.groovy.control.ClassNodeResolver.resolveName(ClassNodeResolver.java:128)
  	at org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClassNullable(AsmReferenceResolver.java:59)
  	at org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClass(AsmReferenceResolver.java:46)
  	at org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveNonArrayType(AsmReferenceResolver.java:81)
  	at org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveType(AsmReferenceResolver.java:72)
  	at org.codehaus.groovy.ast.decompiled.MemberSignatureParser.createMethodNode(MemberSignatureParser.java:55)
  	at org.codehaus.groovy.ast.decompiled.DecompiledClassNode.lazyInitMembers(DecompiledClassNode.java:195)
  	at org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getDeclaredMethods(DecompiledClassNode.java:121)
  	at org.codehaus.groovy.ast.ClassNode.getMethods(ClassNode.java:912)
  	at org.codehaus.groovy.ast.ClassNode.tryFindPossibleMethod(ClassNode.java:1280)
  	at org.codehaus.groovy.control.StaticImportVisitor.transformMethodCallExpression(StaticImportVisitor.java:275)
  	at org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:113)
  	at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:144)
  	at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
  	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:110)
  	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:121)
  	at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:55)
  	at org.codehaus.groovy.control.StaticImportVisitor.visitConstructorOrMethod(StaticImportVisitor.java:89)
  	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructor(ClassCodeVisitorSupport.java:128)
  	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1099)
  	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:54)
  	at org.codehaus.groovy.control.StaticImportVisitor.visitClass(StaticImportVisitor.java:83)
  	at org.codehaus.groovy.control.CompilationUnit$14.call(CompilationUnit.java:699)
  	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1087)
  	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:631)
  	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:609)
  	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:586)
  	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:354)
  	at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:87)
  	at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:323)
  	at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:320)
  	at org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:147)
  	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:318)
  	at org.gradle.groovy.scripts.internal.DefaultScriptCompilationHandler.compileScript(DefaultScriptCompilationHandler.java:137)
  	at org.gradle.groovy.scripts.internal.DefaultScriptCompilationHandler.compileToDir(DefaultScriptCompilationHandler.java:97)
  	at org.gradle.groovy.scripts.internal.BuildOperationBackedScriptCompilationHandler$2.run(BuildOperationBackedScriptCompilationHandler.java:54)
  	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:300)
  	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:292)
  	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:174)
  	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:90)
  	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)

According to https://issues.apache.org/jira/browse/GROOVY-8727 this should be fixed in Groovy 2.5.3 which should be released "this or next week".

[harbby]

Scala can be upgraded to 2.11.12 to support

[lsaint]

MacOS Gradle4.10.2 Java11 not supported:

Could not determine java version from '11'.
java.lang.IllegalArgumentException: Could not determine java version from '11'.
at org.gradle.api.JavaVersion.toVersion(JavaVersion.java:72)
at org.gradle.api.JavaVersion.current(JavaVersion.java:82)

[blindpirate]

@lsaint From the stacktrace you posted, it doesn't look like 4.10.2. Can you please double-check it?

[oehme]

@lsaint Please update the version in your gradle-wrapper.properties. It doesn't matter what you have installed on your system when using the wrapper. The wrapper will use what's specified in the wrapper.properties.

[danieldietrich]

@lsaint @oehme I see no problem. I build Vavr v1.0 with Gradle 4.10.2 and Java 11, both on a Mac and on Linux. My Travis CI builds even run with JDK12 (ea).

[oehme]

@danieldietrich Yes, there are only some minor corner cases that don't work. Overall Java 11 support is pretty solid already.

[marcphilipp]

Done in #7068, #7070, and #7323.

[matteocollina]

With java 11, it works editing (gradle/wrapper/gradle-wrapper.properties):
distributionUrl=https://services.gradle.org/distributions/gradle-4.10.2-all.zip

[asarkar]

@danieldietrich Vavr seems to be using Maven, and not Gradle (I see a pom.xml but no build.gradle). I'm trying to get Gradle working with JPMS, so if you've a modular project somewhere built with Gradle, I'll be interested in seeing it.

[danieldietrich]

Hi @asarkar,

please take a look at the commit 41cd78f. It is the v1.0.0 branch of Vavr, which uses Gradle, Java 11 & Java modules.

(branches are fluctuating a bit because the next major release is in the make...)

Hope that helps! 🙂

[rgoldberg]

@asarkar,

Do you want an example of a Gradle build that uses modules in its build (e.g., its JavaCompiles use the module path), or do you just want to see how to create a modular jar using Gradle (but without using modules in the actual build)?

I only see the latter in Vavr v1.0.0.

If you want the former, I modified Gradle’s experimental JPMS support plugin. My plugin name isn’t finalized, but it’s currently available as rgoldberg.experimental-jigsaw.

There are a few issues with Gradle 5.0-rc-1, but in general, it works with 4.10.2. There are a few issues with CreateStartScripts, though, due to it being hardcoded to work with the class path.

Currently, you just apply the plugin, and, in standard cases, if you have a module-info.java in your source set, it should automatically use the module path for many Java tasks. I haven’t finished supporting Kotlin, and haven’t yet started supporting other languages.

It currently doesn’t have any configuration other than applying the plugin, but, in the future, I’ll add a DSL for manually configuring JPMS options, and for overriding the plugin’s auto JPMS setup. In the meantime, you can add manual JPMS options as task string options, or you can let me know where my auto config doesn’t work for you, and maybe I can improve it to avoid manual option setup.

If you want to look at the code whose binary is deployed on the plugin portal, you need to look at the renamed-plugin branch in my GitHub fork.

[asarkar]

@rgoldberg

example of a Gradle build that uses modules

^^^ that.

I managed to create a Java 9 modularized project that builds with Gradle. As I mentioned in vavr-io/vavr#2316, the Gradle official modularization example uses a very convoluted project to demonstrate a complex idea like JPMS, and ends up deviating from the point. The lack of official JPMS support is also surprising, considering Java 11 is GA now, and 8 EOL, so anyone caring about their system should upgrade to 9+.

Clearly, Gradle is far from ready to embrace JPMS. Thanks for forking the jigsaw plugin, but for obvious reasons, I don't want to use something like that in production code. I'll be evaluating a migration strategy for our projects, and whether it is worth undertaking the modularization effort.

[oehme]

The lack of official JPMS support is also surprising, considering Java 11 is GA now, and 8 EOL, so anyone caring about their system should upgrade to 9+.

Using JPMS is not required for using Java 9+. You can run with the classpath just as before.

Before you give yourself the trouble of using the JPMS, ask yourself what you need it for. If you don't have a very strong reason (and most projects I've seen don't), I'd stay away from it.

Note that this issue is not about JPMS support, only about running Gradle on Java 11, so please keep on topic :)

[asarkar]

@oehme

Note that this issue is not about JPMS support, only about running Gradle on Java 11

That’s like saying the postal workers who deliver Christmas presents to Afghanistan are war veterans :) If we simply wanted to compile code, why Gradle, a shell script would do that. “Running” on Java 11 means being able to build a project on Java 11, with whatever features Java 11 supports. Whether people need JPMS or not is their business; that doesn’t hide the fact that Gradle is not Java 9+ compatible.