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 · 29 comments

Comments

Projects
None yet
@blindpirate
Member

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

This comment has been minimized.

Show comment
Hide comment
@thc202

thc202 May 14, 2018

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@marcphilipp

marcphilipp Jun 27, 2018

Member

A bug which is already submitted to Oracle

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

Member

marcphilipp commented Jun 27, 2018

A bug which is already submitted to Oracle

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

@blindpirate

This comment has been minimized.

Show comment
Hide comment
@blindpirate

blindpirate Jun 27, 2018

Member

@marcphilipp I updated my content.

Member

blindpirate commented Jun 27, 2018

@marcphilipp I updated my content.

@marcphilipp

This comment has been minimized.

Show comment
Hide comment
@marcphilipp

marcphilipp Jun 27, 2018

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@blindpirate
Member

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

This comment has been minimized.

Show comment
Hide comment
@ijuma

ijuma Jul 5, 2018

Contributor

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?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@blindpirate

blindpirate Jul 5, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@marcphilipp

marcphilipp Jul 5, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@ijuma

ijuma Jul 5, 2018

Contributor

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

Contributor

ijuma commented Jul 5, 2018

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

@ijuma

This comment has been minimized.

Show comment
Hide comment
@ijuma

ijuma Jul 5, 2018

Contributor

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)

Contributor

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)

@atorok

This comment has been minimized.

Show comment
Hide comment
@atorok

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

atorok 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

This comment has been minimized.

Show comment
Hide comment
@blindpirate

blindpirate Jul 9, 2018

Member

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

Member

blindpirate commented Jul 9, 2018

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

@oehme

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Jul 9, 2018

Member

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.

Member

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.

@atorok

This comment has been minimized.

Show comment
Hide comment
@atorok

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

atorok 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

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Jul 9, 2018

Member

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
Member

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

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Aug 6, 2018

Member

We can't announce Java 11 support without all our tests passing, which is currently blocked by spockframework/spock#843

Member

oehme commented Aug 6, 2018

We can't announce Java 11 support without all our tests passing, which is currently blocked by spockframework/spock#843

@Ealrann

This comment has been minimized.

Show comment
Hide comment
@Ealrann

Ealrann Aug 18, 2018

Hello,
Do you plan to implement a native support of Java 9 modules in this epic?

Ealrann commented Aug 18, 2018

Hello,
Do you plan to implement a native support of Java 9 modules in this epic?

@oehme

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Aug 18, 2018

Member

No, that's what #890 is for.

Member

oehme commented Aug 18, 2018

No, that's what #890 is for.

@Ealrann

This comment has been minimized.

Show comment
Hide comment
@Ealrann

Ealrann Aug 18, 2018

Oh, thank you :')

Ealrann commented Aug 18, 2018

Oh, thank you :')

@oehme

This comment has been minimized.

Show comment
Hide comment
@oehme
Member

oehme commented Sep 12, 2018

@magJ

This comment has been minimized.

Show comment
Hide comment
@magJ

magJ Sep 26, 2018

Java 11 is now generally available.

magJ commented Sep 26, 2018

Java 11 is now generally available.

@marcphilipp

This comment has been minimized.

Show comment
Hide comment
@marcphilipp

marcphilipp Sep 26, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@harbby

harbby Sep 27, 2018

Scala can be upgraded to 2.11.12 to support

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

This comment has been minimized.

Show comment
Hide comment
@lsaint

lsaint 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)

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

This comment has been minimized.

Show comment
Hide comment
@blindpirate

blindpirate Oct 4, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Oct 4, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@danieldietrich

danieldietrich 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).

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

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Oct 4, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@marcphilipp

marcphilipp Oct 15, 2018

Member

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

Member

marcphilipp commented Oct 15, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment