siordache
commented
3 years ago Yes, ASM was most likely the cause. I upgraded to ASM 9.1 in release 2.23.4.
Closed msgilligan closed 3 years ago
siordache
commented
3 years ago Yes, ASM was most likely the cause. I upgraded to ASM 9.1 in release 2.23.4.
msgilligan
commented
3 years ago Thanks for the quick turnaround! I tried the new version and am getting the same failure/stacktrace.
Perhaps the problem is related to this:
building with Gradle running JDK15 and a JDK16 javaToolchain
I'm running Gradle 6.8.3 under JDK15, but using a JDK16 toolchain and jpackage tool, but createMergedModuleAction is running under JDK15, right?
Looking at the key section of the stack trace:
Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported major.minor version 60.0
at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1088)
at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:192)
at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129)
at org.beryx.jlink.util.Util.getModuleDescriptor(Util.groovy:371)
at org.beryx.jlink.util.ModuleManager$_closure1.doCall(ModuleManager.groovy:32)
at org.beryx.jlink.util.ModuleManager$_closure1.call(ModuleManager.groovy)This would be running under JDK15, so that's probably the issue.
I'll try running with a pre-release Gradle 7 under JDK 16 and let you know what happens.
msgilligan
commented
3 years ago With the latest Gradle 7 nightly and JDK16 (16.0.0, AdoptOpenJDK Hotspot) I get the following error:
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':portfolio-omnimarketcap:createMergedModule'.
> class org.beryx.jlink.util.PackageCollection (in unnamed module @0x368cface) cannot access class jdk.internal.org.objectweb.asm.Type (in module java.base) because module java.base does not export jdk.internal.org.objectweb.asm to unnamed module @0x368cfaceWith the key bit of stack trace being:
Caused by: java.lang.IllegalAccessError: class org.beryx.jlink.util.PackageCollection (in unnamed module @0x368cface) cannot access class jdk.internal.org.objectweb.asm.Type (in module java.base) because module java.base does not export jdk.internal.org.objectweb.asm to unnamed module @0x368cface
at org.beryx.jlink.util.PackageCollection.addDescriptor(PackageCollection.groovy:38)
at org.beryx.jlink.util.PackageUseScanner.visitAnnotation(PackageUseScanner.groovy:196)
at org.beryx.jlink.shadow.asm.ClassReader.accept(ClassReader.java:586)
at org.beryx.jlink.shadow.asm.ClassReader.accept(ClassReader.java:401)
at org.beryx.jlink.util.PackageUseScanner$_scan_closure1.doCall(PackageUseScanner.groovy:213)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.beryx.jlink.util.Util$_scanDir_closure6$_closure21.doCall(Util.groovy:225)
at org.beryx.jlink.util.Util$_scanDir_closure6$_closure21.call(Util.groovy)
at org.beryx.jlink.util.Util$_scanDir_closure6.doCall(Util.groovy:224)
at org.beryx.jlink.util.Util$_scanDir_closure6.call(Util.groovy)
at org.beryx.jlink.util.Util.scanDir(Util.groovy:221)
at org.beryx.jlink.util.Util.scan(Util.groovy:214)
at org.beryx.jlink.util.PackageUseScanner.scan(PackageUseScanner.groovy:208)
at org.beryx.jlink.util.PackageUseScanner$scan.call(Unknown Source)
at org.beryx.jlink.util.SuggestedMergedModuleInfoBuilder.getRequiresBuilders(SuggestedMergedModuleInfoBuilder.groovy:106)
at org.beryx.jlink.util.SuggestedMergedModuleInfoBuilder.getModuleInfo(SuggestedMergedModuleInfoBuilder.groovy:45)
at org.beryx.jlink.impl.CreateMergedModuleTaskImpl.genModuleInfoBadass(CreateMergedModuleTaskImpl.groovy:121)
at org.beryx.jlink.impl.CreateMergedModuleTaskImpl.genModuleInfo(CreateMergedModuleTaskImpl.groovy:69)
at org.beryx.jlink.impl.CreateMergedModuleTaskImpl.execute(CreateMergedModuleTaskImpl.groovy:48)
at org.beryx.jlink.CreateMergedModuleTask.createMergedModuleAction(CreateMergedModuleTask.groovy:122)OK, I think I've narrowed the problem down. It seems that using additive = true in the mergedModule closure is causing the problem. To try to find a specific dependency that might be causing the problem in my (not public) OmniMarketCap project I tried building just the suggestMergedModuleInfo target and that failed with the same error.
The 3 sample apps in the Supernaut.FX build have been building correctly, so I tried to see if I could trigger the failure in that project. So I did the following:
:supernaut-fx-sample-hello:suggestMergedModuleInfo in the Github Action (on yet another branch) -- failure: https://github.com/SupernautApp/SupernautFX/actions/runs/677324672Here's the Gradle Build Scan of the failure: https://scans.gradle.com/s/6pkdbf5oqyvho
So you should be able to check out the msgilligan-gradle-7 branch and use ./gradlew :supernaut-fx-sample-hello:suggestMergedModuleInfo to reproduce the failure (using AdoptOpenJDK 16)
msgilligan
commented
3 years ago I was able to get the OmniMarketCap build working, by generating the mergedModule block under JDK15 and copy-pasting it into build.gradle (replacing the additive = true line) and then building with JDK16. I also had to removing the lines:
excludeProvides service: 'javax.money.spi.CurrencyProviderSpi'
provides 'javax.money.spi.CurrencyProviderSpi' with 'org.javamoney.moneta.spi.ConfigurableCurrencyUnitProvider, org.javamoney.moneta.spi.JDKCurrencyProvider, org.consensusj.currency.BitcoinCurrencyProvider, foundation.omni.money.OmniCurrencyProvider'
It turns out that the excludeProvides line and a followingprovides were not necessary (no-longer necessary?) because the suggested mergedModule block had discovered all the providers correctly.
siordache
commented
3 years ago There are a few places in the plugin's code where the method ModuleDescriptor.read(InputStream) is called. These calls fail when the InputStream argument contains Java 16 bytecode and Gradle uses Java 15.
I will try to execute these calls in a separate process that uses the required toolchain. It's a bit of a hack but it should work. I will do a new release in the next few days.
msgilligan
commented
3 years ago There are a few places in the plugin's code where the method ModuleDescriptor.read(InputStream) is called. These calls fail when the InputStream argument contains Java 16 bytecode and Gradle uses Java 15.
Except the error above (see https://scans.gradle.com/s/6pkdbf5oqyvho ) is running Gradle under JDK 16.
(I think this problem might have something to do with changed default visibility in JDK 16)
msgilligan
commented
3 years ago p.s. I could create a new issue for the Gradle 7/JDK 16 error:
org.beryx.jlink.util.PackageCollection (in unnamed module @0x368cface)cannot access class jdk.internal.org.objectweb.asm.Type (in module java.base)because module java.base does not export jdk.internal.org.objectweb.asm to unnamed module @0x368cfaceNo need to create a new issue because I already identified the cause: an autocomplete fail in PackageCollection.
I had entered:
import jdk.internal.org.objectweb.asm.Typeinstead of
import org.objectweb.asm.Typeimport jdk.internal.org.objectweb.asm.Type
Yeah, I was surprised by that package path. Was thinking it was weird that OpenJDK had created some internal support for ASM...
msgilligan
commented
3 years ago I see that Gradle 7 RC1 came out yesterday, so i'll be updating to RC1.
siordache
commented
3 years ago I just released 2.23.5, which fixes the jdk.internal.org.objectweb.asm error and also executes the ModuleDescriptor.read() calls in a separate process, using the configured toolchain.
I tested the plugin with one of my projects and it worked fine with Gradle 7.0-rc-1. However, I had some problems with Gradle 6.8.3 under JDK15, using a JDK16 toolchain, because of this Gradle bug:
java.lang.IllegalAccessError: class org.gradle.internal.compiler.java.ClassNameCollector (in unnamed module @0x1dd79f5c) cannot access class com.sun.tools.javac.code.Symbol$TypeSymbol (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.code to unnamed module @0x1dd79f5cMy workaround was to replace
java {
toolchain {
languageVersion = JavaLanguageVersion.of(16)
}
}with
tasks.withType(JavaCompile).configureEach {
options.forkOptions.jvmArgs.addAll( ['--add-opens', 'jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED'] )
def toolchainHome = javaToolchains.compilerFor {
languageVersion = JavaLanguageVersion.of(16)
}.get().metadata.installationPath.asFile.absolutePath
options.forkOptions.executable = "$toolchainHome/javac"
}So, updating to Gradle 7.0-rc-1 is probably the best option.
msgilligan
commented
3 years ago OK, I upgraded 3 branches of SupernautFX to 2.23.5 and all are passing Github CI -- 2.23.5 looks good!
suggestMergedModuleInfo task) -- was broken, now fixed(I had already applied the '--add-opens' workaround for the Gradle bug.)
I would upgrade master to Gradle 7.0-rc-1, but the Gradle license plugin still hasn't released a fix for https://github.com/hierynomus/license-gradle-plugin/issues/179 ...
... and I just noticed that it is forked and released by @siordache -- you're single-handedly fixing all my blockers to a release built on JDK 16! OK, I can upgrade to Gradle 7.0-rc-1 on the master branch, now!
Update: I fixed a typo where in 2 places I accidentally put JDK 17 where I meant JDK 16.
siordache
commented
3 years ago Yes, I also need the hierynomus/license-gradle-plugin. For JDK 16 I use jitpack to get the version from my fork: https://jitpack.io/#siordache-forks/license-gradle-plugin/v0.16.1
msgilligan
commented
3 years ago OK, after https://github.com/SupernautApp/SupernautFX/commit/941c7282836c10c2923687cc484a6b9fea42c647 Supernaut.FX master is using JDK 16 (for both the Gradle daemon and the Java Toolchain), Gradle 7.0-rc-1, BA JLink 2.23.5, and your Jitpack build of license plugin and looking good!
I've been successfully building with Gradle running JDK15 and a JDK16 javaToolchain (in https://github.com/SupernautApp/SupernautFX, for example)
However, in another (unfortunately not Open Source) project, with a similar configuration, I'm getting:
Perhaps the ASM dependency needs to be upgraded to ASM 9.0 or 9.1?