Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java 11 support #5120

Closed
blindpirate opened this issue Apr 20, 2018 · 36 comments
Closed

Java 11 support #5120

blindpirate opened this issue Apr 20, 2018 · 36 comments
Assignees
Labels
Milestone

Comments

@blindpirate
Copy link
Member

@blindpirate blindpirate commented Apr 20, 2018

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.

@blindpirate blindpirate added the epic label Apr 20, 2018
@blindpirate blindpirate added this to the 4.9 RC 1 milestone Apr 20, 2018
@thc202
Copy link
Contributor

@thc202 thc202 commented May 14, 2018

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
Copy link
Member

@marcphilipp marcphilipp commented Jun 27, 2018

A bug which is already submitted to Oracle

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

@blindpirate
Copy link
Member Author

@blindpirate blindpirate commented Jun 27, 2018

@marcphilipp I updated my content.

@marcphilipp
Copy link
Member

@marcphilipp marcphilipp commented Jun 27, 2018

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
Copy link
Member Author

@blindpirate blindpirate commented Jun 27, 2018

@marcphilipp Exactly.

@oehme oehme modified the milestones: 4.9 RC1, 4.10 RC1 Jun 28, 2018
@oehme oehme assigned oehme and blindpirate and unassigned oehme Jun 28, 2018
@ijuma
Copy link
Contributor

@ijuma ijuma commented Jul 5, 2018

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
Copy link
Member Author

@blindpirate blindpirate commented Jul 5, 2018

@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
Copy link
Member

@marcphilipp marcphilipp commented Jul 5, 2018

@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
Copy link
Contributor

@ijuma ijuma commented Jul 5, 2018

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

@ijuma
Copy link
Contributor

@ijuma ijuma commented Jul 5, 2018

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
Copy link

@alpar-t alpar-t commented Jul 9, 2018

@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
Copy link
Member Author

@blindpirate blindpirate commented Jul 9, 2018

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

@oehme
Copy link
Contributor

@oehme oehme commented Jul 9, 2018

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
Copy link

@alpar-t alpar-t commented Jul 9, 2018

@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
Copy link
Contributor

@oehme oehme commented Jul 9, 2018

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
Copy link
Contributor

@oehme oehme commented Sep 12, 2018

@magJ
Copy link

@magJ magJ commented Sep 26, 2018

Java 11 is now generally available.

@marcphilipp
Copy link
Member

@marcphilipp marcphilipp commented Sep 26, 2018

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
Copy link

@harbby harbby commented Sep 27, 2018

Scala can be upgraded to 2.11.12 to support

@oehme oehme assigned marcphilipp and unassigned oehme Oct 1, 2018
@marcphilipp marcphilipp modified the milestones: 5.0 M1, 5.0 RC1 Oct 2, 2018
@lsaint
Copy link

@lsaint lsaint commented Oct 4, 2018

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
Copy link
Member Author

@blindpirate blindpirate commented Oct 4, 2018

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

@oehme
Copy link
Contributor

@oehme oehme commented Oct 4, 2018

@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
Copy link

@danieldietrich danieldietrich commented Oct 4, 2018

@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
Copy link
Contributor

@oehme oehme commented Oct 4, 2018

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

@marcphilipp
Copy link
Member

@marcphilipp marcphilipp commented Oct 15, 2018

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

@matteocollina
Copy link

@matteocollina matteocollina commented Oct 23, 2018

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

@asarkar
Copy link

@asarkar asarkar commented Nov 2, 2018

@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
Copy link

@danieldietrich danieldietrich commented Nov 2, 2018

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
Copy link
Contributor

@rgoldberg rgoldberg commented Nov 2, 2018

@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
Copy link

@asarkar asarkar commented Nov 2, 2018

@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
Copy link
Contributor

@oehme oehme commented Nov 2, 2018

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
Copy link

@asarkar asarkar commented Nov 2, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.