JDK-8332744 : [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-05-22
  • Updated: 2025-02-20
  • Resolved: 2024-11-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 24
24 b23Fixed
Related Reports
Causes :  
Causes :  
Causes :  
Cloners :  
Cloners :  
Relates :  
Description
The following example shows that 'compiler.warn.sun.proprietary' diagnostics are not emitted if --system is configured to an earlier JDK version. I expected the diagnostics to be emitted for both configurations.

The diagnostics are consistently emitted for different configurations of --release.

cat A.java
class A {
  sun.misc.Unsafe theUnsafe;
}

$JAVA21_HOME/bin/java -fullversion
openjdk full version "21.0.2+13-58"
$JAVA11_HOME/bin/java -fullversion
openjdk full version "11.0.16+8"

$JAVA21_HOME/bin/javac --system $JAVA21_HOME A.java
A.java:2: warning: Unsafe is internal proprietary API and may be removed in a future release
  sun.misc.Unsafe theUnsafe;
          ^
1 warning

$JAVA21_HOME/bin/javac --system $JAVA11_HOME A.java
...
no diagnostics
Comments
Changeset: 839de82c Branch: master Author: Liam Miller-Cushon <cushon@openjdk.org> Date: 2024-11-05 17:06:04 +0000 URL: https://git.openjdk.org/jdk/commit/839de82c314697d7461b77caa9d85407e3578de3
05-11-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/19397 Date: 2024-05-24 15:32:09 +0000
09-07-2024

Thanks Jan! I was able to reproduce following your instructions, and I belatedly see this is mentioned in https://github.com/openjdk/jdk/blob/master/doc/testing.md#configuration including how to use createJMHBundle.sh to set up the JMH jars. Migrating those microbenchmarks from sun.misc.Unsafe to jdk.internal.misc.Unsafe fixes the build errors: https://github.com/openjdk/jdk/pull/19397
24-05-2024

What I tried is: a) configuring the build with `--with-jmh=<directory>`, where directory contains the JMH, in my case: 'commons-math3-3.6.1.jar jmh-core-1.37.jar jmh-generator-annprocess-1.37.jar jopt-simple-5.0.4.jar' b) running `make clean images build-microbenchmark` Passes without the JDK-8331081 patch, and files with it. I guess the build is in `make/test/BuildMicrobenchmark.gmk`
24-05-2024

[~dcubed] do you have any pointers on how I could reproduce the microbenchmark failures mentioned in https://bugs.openjdk.org/browse/JDK-8332740? I see the files mentioned in the build log at https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench, but I don't see public make targets for them, and tier1 passed for me when I tested the original change.
22-05-2024

The original fix was backed out because files in test/micro/ are referencing internal APIs and being built with -Werror enabled: https://bugs.openjdk.org/browse/JDK-8332740 I will investigate whether it's possible to fix that build issue and redo the fix.
22-05-2024