JDK-8349846 : [REDO] [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 25
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-02-11
  • Updated: 2025-05-08
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.
Other
tbdUnresolved
Related Reports
Cloners :  
JDK-8332744 - [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version
Relates :  
JDK-8349058 - 'internal proprietary API' warnings make javac warnings unusable
Description
Currently sunapi (compiler.warn.sun.proprietary) diagnostics are not emitted if --system is configured to an earlier JDK version, or if -XDignore.symbol.file is configured. Ideally sunapi diagnostics would be reported consistently in both of those configurations.

See test coverage here: https://github.com/openjdk/jdk/blob/1ab1c1d53b86228be85aac96fa5d69db39ac6317/test/langtools/tools/javac/options/system/SystemSunProprietary.java#L94-L100

There are some challenges to doing this, as discussed in JDK-8349058. sunapi are mandatory, unsuppressible warnings, so for compilations using -Werror introducing a sunapi warning that was not shown previously will break the build. Some of the remaining uses of APIs that result in warnings to not have easy migration paths (JDK-8349056). To work around this, -XDignore.symbol.file has become somewhat widely used as an ad-hoc suppression mechanism for sunapi diagnostics.
Comments
I'm not that motivated to try to push this forward again. If it happened, I think the best approach might be to ensure that -XDignore.symbol.file continues to work as undocumented suppression mechanism for both --system and --release, since the previous rollbacks established that having a supported suppression mechanism for sunapi diagnostics is a requirement, but per JDK-8349848 the preference is to use -XDignore.symbol.file as that suppression mechanism instead of -Xlint/-Werror: https://mail.openjdk.org/pipermail/compiler-dev/2025-February/029417.html
08-05-2025
My personal opinion: given this has been reverted twice already, I think the bar for re-including this is fairly high. It is not clear to me if any possible change clears that bar. IMO, the reasons to use `--system` are fairly limited (given we have `--release`), and complex. So, advanced users using `--system` probably can accept the inconvenience of not getting the warning. I do, in principle, agree the warning should ideally be reported, but so far, it seemed to cause more problems than it is worth. I will not close this report at this time, but I think there should be a fairly strong reasoning on why we should do this, and why this is useful to a somewhat broad(er) range of users.
08-05-2025
Supporting lint control of sunapi diagnostics is contentious (JDK-8350135, https://github.com/openjdk/jdk/pull/23650), if this happens it may be necessary to preserve -XDignore.symbol.file as a de-facto supported suppression mechanism.
04-03-2025