-
Notifications
You must be signed in to change notification settings - Fork 34
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
Startup issues on Java 20 #215
Comments
Can you post a full stack trace? Are you running Forbiddenapis in Gradle that's iraself running in Java 20? That is indeed not yet supported, but should not break. Do you have Generally, official support will come with release of Java 20 and when ASM was updated. |
Thanks @uschindler - I'll close this. We run builds for multiple Java versions and we don't really need to have forbiddenapis run on all builds. |
Anyways, do you know the full stacktrace? I wonder why forbiddenapis fails on plugin initialization where it does not do any ASM related stuff (or should not do it). |
The issue originally happened in https://ci-builds.apache.org/job/POI/job/POI-DSL-1.20/1/console but now when I try to reproduce it on my laptop, it looks Gradle itself won't run with jdk 20-ea. I'm happy to just ignore this issue and have forbiddenapis enforcement happen on other Java versions. |
For me it reproduces locally, full stacktrace is as follows Make sure to call gradle as
the "--no-daemon" was important to get the proper stacktrace
|
Hi,
In fact the problem is simple: Gradle in the version you use does not support the Java version you are running on. I can't fix this. forbiddenapis is just the plugin that fails first. Under other circumstances Gradle will report the same when it compiles "settings.gradle" or similar plain text files. When this happens depends on what code is used. If setting.gradle does not refer to JDK's classes, some later code like build.gradle may fail (when build.gradle refers or imports classes from JDK). To correctly compile and test POI against Java 20, you have to start Gradle with (ideally 17) and just have the java compile and test runner use a toolkit-provided JDK. |
Thanks for the detailed explanation! |
This fails because of the lack of signatures for jdk20, e.g.
Ideally it should walk the bundle to what is supported, rather than require waiting for a release because the newer jdk version does not have a signature yet. Alternatively, these checks could be an ErrorProne extension and not need to inspect the bytecode directly and decoupling it from the jdk release. |
Hi, What is not supported is only checking the compiled classes against the explicitely given signatures files of a not yet supported java version. So instead of complaining here make sure:
Always execute the checks against the version your are compiling against. Everything else is not a correct setup. Sorry for complications with some build system inefficiencies. Unfortunatley Maven has no easy and documented way (the project property trick is just reliyung on the project property of the compiler plugin and it reads it) to set the release/target version for a project like Gradle does. |
The original problem reported here was about Gradle not working on Java 20 at all. This was unrelated to the plugin, it was just the first one running into this. Actually the plugin bottstrap was already improved for this, so it will have precompiled Groovy code for the plugin (see #221). Everything else is on the way. I will check later today if ASM 9 was updated for recent bytecode (version 21), so we get support for 20 (signatures) and 21 (bytecode). @ben-manes: There are no plans to rewrite this plugin against errorprone. To me scanning bytecode has more options, because you will also find hidden forbiddenapis calls. Elasticearch for example scans external JAR files for invalid calls to |
ASM 9.5 was relased. Will upgrade, then add new signatures and trigger a release. |
No problem, it was just an idea if simpler for you to maintain. Everything always worked great for me, I run this task at a supported jdk and others at higher (like EA). Just moved up builds and was looking if jdk20 signatures were ready, but not in a rush. Thanks! |
Adding the option to use "best possible" jdk-XXX signatures is some idea, but haven't implemented it. This would be helpful indeed. |
Here is the PR for Java 20: #224 |
Get this issue:
The text was updated successfully, but these errors were encountered: