Skip to content

Commit

Permalink
Add support for Java 16 and update ASM to version 9.1
Browse files Browse the repository at this point in the history
  • Loading branch information
uschindler committed Apr 17, 2021
1 parent b131231 commit ac754c4
Show file tree
Hide file tree
Showing 7 changed files with 651 additions and 5 deletions.
2 changes: 2 additions & 0 deletions build.xml
Original file line number Diff line number Diff line change
Expand Up @@ -63,6 +63,7 @@
<equals arg1="${-cleaned.specification.version}" arg2="13"/>
<equals arg1="${-cleaned.specification.version}" arg2="14"/>
<equals arg1="${-cleaned.specification.version}" arg2="15"/>
<equals arg1="${-cleaned.specification.version}" arg2="16"/>
</or>
</condition>

Expand Down Expand Up @@ -156,6 +157,7 @@
<equals arg1="${build.java.runtime}" arg2="13"/>
<equals arg1="${build.java.runtime}" arg2="14"/>
<equals arg1="${build.java.runtime}" arg2="15"/>
<equals arg1="${build.java.runtime}" arg2="16"/>
</or>
</condition>

Expand Down
2 changes: 1 addition & 1 deletion ivy.xml
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@
<!DOCTYPE ivy-module [
<!ENTITY maven.version "2.0">
<!ENTITY gradle.version "3.2">
<!ENTITY asm.version "9.0">
<!ENTITY asm.version "9.1">
<!ENTITY jarjar.asm.version "5.2">
]>
<ivy-module version="2.0">
Expand Down
6 changes: 3 additions & 3 deletions src/main/docs/bundled-signatures.html
Original file line number Diff line number Diff line change
Expand Up @@ -29,14 +29,14 @@ <h1>Bundled Signatures Documentation</h1>
<li><strong><tt>jdk-unsafe-*</tt>:</strong> Signatures
of &quot;unsafe&quot; methods that use default charset, default locale, or default timezone. For server applications it is very
stupid to call those methods, as the results will definitely not what the user wants
(for Java <tt>*</tt> = 1.7, 1.8, 9, 10, 11, 12, 13, 14, 15; Ant / Maven / Gradle automatically add the compile Java version).</li>
(for Java <tt>*</tt> = 1.7, 1.8, 9, 10, 11, 12, 13, 14, 15, 16; Ant / Maven / Gradle automatically add the compile Java version).</li>

<li><strong><tt>jdk-deprecated-*</tt>:</strong> This disallows all deprecated
methods from the JDK (for Java <tt>*</tt> = 1.7, 1.8, 9, 10, 11, 12, 13, 14, 15; Ant / Maven / Gradle automatically add the compile Java version).</li>
methods from the JDK (for Java <tt>*</tt> = 1.7, 1.8, 9, 10, 11, 12, 13, 14, 15, 16; Ant / Maven / Gradle automatically add the compile Java version).</li>

<li><strong><tt>jdk-internal-*</tt>:</strong> Lists all internal packages of the JDK as of <code>Security.getProperty(&quot;package.access&quot;)</code>.
Calling those methods will always trigger security manager and is completely forbidden from Java 9 on
(for Java <tt>*</tt> = 1.7, 1.8, 9, 10, 11, 12, 13, 14, 15; Ant / Maven / Gradle automatically add the compile Java version, <em>since forbiddenapis v2.1</em>).</li>
(for Java <tt>*</tt> = 1.7, 1.8, 9, 10, 11, 12, 13, 14, 15, 16; Ant / Maven / Gradle automatically add the compile Java version, <em>since forbiddenapis v2.1</em>).</li>

<li><strong><tt>jdk-non-portable</tt>:</strong> Signatures of all non-portable (like <code>com.sun.management.HotSpotDiagnosticMXBean</code>)
or internal runtime APIs (like <code>sun.misc.Unsafe</code>). This is a superset of <tt>jdk-internal</tt>.<br>
Expand Down
2 changes: 1 addition & 1 deletion src/main/java/de/thetaphi/forbiddenapis/AsmUtils.java
Original file line number Diff line number Diff line change
Expand Up @@ -179,7 +179,7 @@ private static byte[] readStream(final InputStream in) throws IOException {
@SuppressWarnings("unused")
public static ClassReader readAndPatchClass(InputStream in) throws IOException {
final byte[] bytecode = readStream(in);
if (false) patchClassMajorVersion(bytecode, Opcodes.V15 + 1, Opcodes.V15);
if (false) patchClassMajorVersion(bytecode, Opcodes.V16 + 1, Opcodes.V16);
return new ClassReader(bytecode);
}

Expand Down
Loading

6 comments on commit ac754c4

@pzygielo
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With JDK17 almost ready, could we have new FA release with JDK16 signatures, please?

@uschindler
Copy link
Member Author

@uschindler uschindler commented on ac754c4 Aug 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, yes. I had no time and because of some initial issues with JDK 17, the whole thing delayed. Also due to much work it was impossible to release in time.

Generally, you won't need a separate release for JDK 16, as there were no changes. Forbiddenapis works fine with JDK 16, you only can't directly refer to signatures specific to this version. Pass JDK 15 and all is fine.

I am planning to make a change to forbiddenapis, to allow releases > the maximum supported and automatically fake signatures files, so passing source/target/relaese won't break builds.

@pzygielo
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for checking and the tip.
I didn't think on setting java version for FA, was using auto-detection (probably from maven.compiler.release) only.

@uschindler
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In genrral you should always set source/target/release, because if you don't, Maven detects the current runtime Java version as "default". And if that is used with forbiddenapis, it would cause issues if you compile code with later versions.

For reproducible builds maven.compiler.release/target/source should always be set and not autodetection used.

In case you write code specifically for JDK 16 or JDK 17, of course you must set release=16/17, but then it's a simple workaround to specifiy an older version in the FA maven plugin.

@pzygielo
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant that I have maven.compiler.release set explicitly (to say 15).
Using newer JDK to compile and check for forbidden APIs works then perfectly fine.
However, as I'm using <bundledSignature>jdk-deprecated</bundledSignature> - I get problem once maven.compiler.release is updated to 16.
Per

* This setting should be identical to the release version used in the compiler plugin starting with Java 9.

This setting should be identical

but I confirm that configuring <releaseVersion>15</releaseVersion> in plugin works fine as well.

@uschindler
Copy link
Member Author

@uschindler uschindler commented on ac754c4 Aug 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All fine. I was not aware that you wanted to explicitely compile against JDK 16, which is quite uncommon! Most people having this issue just forget to use maven.compiler.release at all (which is bad as it is an unreproducible build) and then when using a recent JDK it breaks due to autoused defaults.

Please sign in to comment.