Check fails with "Bundled signatures resource not found: jdk-unsafe-21" despite failOnUnsupportedJava/failOnViolation disabled #233
Comments
kohlschuetter
changed the title
|
Hi, Java 21 signatures are not yet supported. It has nothing to do with the used java runtime. You configured signatures for java 21 (e.g. through compiler config). If they are not found, it is not a bug and wrongly configured settings always cause a failure. Configure targetVersion property with the java version equal to compiler config (see documentation). Normally you would give the release/target version passed to compiler plugin. Normally you have targetVersion or releaseVersion configured on compiler plugin you need to do the same here. FailOnUnsupportedJava does not trigger, because it is about bytecode version of scanned class files. This is unlikely to trigger nowadays. Fail on violation has nothing to do with this issue. |
|
P.S. support for signatures will come soon, the release is planned a few days after Java 21 comes out. |
|
@uschindler If I understand you, being — at least passively — forward compatible to new Java versions is a non-goal? Isn't this a bug as "failOnUnsupportedJava" is supposed to take care of that scenario? |
|
Java 21 bytecode is already supported. The problem is that signatures files are not yet available. As you cannot foresee the future (you need to carefully check diffs), there is the problem that uptodate signatures for deprecated and unsafe apis can only be provided after release of the corresponding java version. There's already a few issues for preparing them. As said before: failOnUnsupportedJava is a legacy feature that only prevents looking into jdk internals in early java versions. It has nothing to do with signature files. The java runtime version is irrelevant for parsing them or checking class files. In short: Since Java 9 this is a non-issue as module system is used to get public method signatures and runtime class file parsing is no longer needed. The option will possibly go away once java 7 support is removed. Actually forbidden apis works perfectly fine with Java 21 or 22, there are just no updated signatures provided yet, which can't be done before it's released. The problem you have is a configuration problem. If you would specify the target java version in your build file, it won't fallback to runtime defaults. The issue here is that there are no forbidden signatures for Java 21 yet. As workaround use the ones of Java 20. |
|
I see. Specifying |
|
I deleted the last comment, sorry. You said "did the trick". There are some plans to add a compatibility layer for newer signatures files automatactially falling back to previous versions and to also simplify the "include" chains in the current variants. There is also the issue that for code compiled against Java 21, we need to remove one specific signature from the unsafe ones (it was fixed upstream) and there's no support for that (see #225). |
|
P.S.: I am on vacation this week, sorry for short answers only. |
When forbidden-apis is too old to support a certain Java version (e.g., 21), we can override the release compliance level via a Maven property and forcibly specify a lower Java version via "forbiddenapis.releaseVersion". This may not always work, but is better than nothing. policeman-tools/forbidden-apis#233
When checking code that is compiled against Java 21 (or Java 22 fwiw), forbiddenapis Maven plugin 3.5.1 fails with the following error:
Here is my Maven configuration:
java -version says:
Since
failOnUnsupportedJava(andfailOnViolation) is set tofalse, I would expect the checks to emit a warning at most and not fail instead. I also wonder if falling back to a supported version is a possibility (e.g., look forjdk-unsafe-21,jdk-unsafe-20, etc. ifjdk-unsafe-22is unavailable).The text was updated successfully, but these errors were encountered: