JDK-8349058 : 'internal proprietary API' warnings make javac warnings unusable
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 24
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-01-30
  • Updated: 2025-02-19
  • Resolved: 2025-02-06
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 JDK 25
24.0.1Fixed 25 b10Fixed
Related Reports
Causes :  
Relates :  
Relates :  
Relates :  
Description
Using this small reproducer:
```java
import sun.misc.Signal;
import sun.misc.Unsafe;

import java.lang.reflect.Field;

public class MyLibrary {

    @SuppressWarnings("removal")
    public static void main(String[] args) throws InterruptedException {
        System.out.println("pageSize = " + UNSAFE.pageSize());

        long pointer = UNSAFE.allocateMemory(8);
        System.out.println("pointer = " + pointer);
        // Imagine some more useful logic with the pointer, just keeping the example short here

        Signal.handle((Signal) new Signal("INT"), signal -> {
            // Imagine some more useful signal handler, just keeping the example short here
            System.out.println("Bye");
            System.exit(0);
        });

        System.out.println("Sleeping");
        Thread.sleep(30 * 1000);
    }

    private static final Unsafe UNSAFE = getUnsafe();

    @SuppressWarnings("restriction")
    private static Unsafe getUnsafe() {
        try {
            Field field = Unsafe.class.getDeclaredField("theUnsafe");
            field.setAccessible(true);
            return (Unsafe) field.get(null);
        } catch (NoSuchFieldException | IllegalAccessException e) {
            throw new Error(e);
        }
    }

}
```

On JDK 24+22 or before, everything is fine:
```
$ javac -Xlint:all -XDignore.symbol.file MyLibrary.java
MyLibrary.java:15: warning: [cast] redundant cast to Signal
        Signal.handle((Signal) new Signal("INT"), signal -> {
                      ^
Note: MyLibrary.java uses or overrides a deprecated API that is marked for removal.
Note: Recompile with -Xlint:removal for details.
1 warning
# Fixing the warning
$ javac -Werror -Xlint:all -XDignore.symbol.file MyLibrary.java
Note: MyLibrary.java uses or overrides a deprecated API that is marked for removal.
Note: Recompile with -Xlint:removal for details.
[exit code success]
```

Compiling it with javac on JDK 24+23 or more recent gives:
```
$ javac -Xlint:all -XDignore.symbol.file MyLibrary.java
MyLibrary.java:1: warning: Signal is internal proprietary API and may be removed in a future release
import sun.misc.Signal;
               ^
MyLibrary.java:2: warning: Unsafe is internal proprietary API and may be removed in a future release
import sun.misc.Unsafe;
               ^
MyLibrary.java:15: warning: Signal is internal proprietary API and may be removed in a future release
        Signal.handle((Signal) new Signal("INT"), signal -> {
                       ^
MyLibrary.java:15: warning: Signal is internal proprietary API and may be removed in a future release
        Signal.handle((Signal) new Signal("INT"), signal -> {
                                   ^
MyLibrary.java:15: warning: [cast] redundant cast to Signal
        Signal.handle((Signal) new Signal("INT"), signal -> {
                      ^
MyLibrary.java:15: warning: Signal is internal proprietary API and may be removed in a future release
        Signal.handle((Signal) new Signal("INT"), signal -> {
        ^
warning: Signal is internal proprietary API and may be removed in a future release
MyLibrary.java:25: warning: Unsafe is internal proprietary API and may be removed in a future release
    private static final Unsafe UNSAFE = getUnsafe();
                         ^
MyLibrary.java:28: warning: Unsafe is internal proprietary API and may be removed in a future release
    private static Unsafe getUnsafe() {
                   ^
MyLibrary.java:30: warning: Unsafe is internal proprietary API and may be removed in a future release
            Field field = Unsafe.class.getDeclaredField("theUnsafe");
                          ^
MyLibrary.java:32: warning: Unsafe is internal proprietary API and may be removed in a future release
            return (Unsafe) field.get(null);
                    ^
Note: MyLibrary.java uses or overrides a deprecated API that is marked for removal.
Note: Recompile with -Xlint:removal for details.
11 warnings

# Fixing the warning
$ javac -Werror -Xlint:all -XDignore.symbol.file MyLibrary.java
...
error: warnings found and -Werror specified
...
1 error
9 warnings
[exit code failure]
```

This shows multiple things:
* These warnings are not actionable at least for sun.misc.Signal, which I filed separately as JDK-8349056. So one cannot just address those warnings as a solution.
* These warnings are a lot of noise, in fact it's so much noise that it becomes very hard to find the actual useful warning in there (the redundant cast). So it hurts the usability of javac warnings significantly.
* As far as I know these warnings cannot be suppressed or hidden to only see the relevant warnings.
* BTW there are already deprecation warnings e.g. for sun.misc.Unsafe, so these warnings feel redundant/unnecessary.
* javac -Werror has become unusable in any Java project using the sunc.misc.* APIs, therefore it is no longer possible to check in CI that there are no javac warnings in a project, if it uses sun.misc.Signal or any other sun.misc classes (as that causes javac to always error with exit code failed).

I think these 'internal proprietary API' warnings should be removed, or be suppressible, so other actionable/useful warnings can still be seen and checked in CI automatically with -Werror.
JDK-8332744 breaks the utility of javac warnings almost completely for any project using sun.misc.* classes (and so many projects do).

Also from the description and comments on JDK-8332744 it's not clear whether it intended to emit these warnings in a non-suppressible way.
Comments
> Based on a chat with the tools folks I think this is a good candidate for a critical request. If you agree, could you add the jdk24u-critical-request label. Thanks, done. I think it's worth considering. The bug will cause new errors in compilations using -Werror if sunapi diagnostics are present, where -XDignore.symbol.file or --system was being relied on to suppress the diagnostics. Backporting the fix should be very safe, it's a clean backout that restores the long-standing previous behavior. So I think the backport is lower risk than leaving this unaddressed.
12-02-2025

[~cushon] Thanks for the fix Liam. Based on a chat with the tools folks I think this is a good candidate for a critical request. If you agree, could you add the jdk24u-critical-request label.
12-02-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk24u/pull/69 Date: 2025-02-11 16:57:52 +0000
11-02-2025

[jdk24u-fix-request] Approval Request from Liam Miller-Cushon backporting this patch fix fixes a usability issue with 'sunapi' diagnostics. Low risk as the backport is backing out the changes made in JDK-8332744 and restoring the long-standing earlier behaviour. The patch applied cleanly, the affected tests pass.
11-02-2025

I'll prepare a backport request for 24u I also filed JDK-8349846 to track redoing this, and filed a couple of linked enhancement ideas that might make that feasible (JDK-8349847, JDK-8349848).
11-02-2025

> It should be possible to backport to JDK 24 updates. Right, that seems useful, is there anything I need to do to request that?
11-02-2025

I doubt there's a realistic chance to backport to JDK 24 (only P1s can be fixed for JDK 24 now, AFAIK). It should be possible to backport to JDK 24 updates.
10-02-2025

Thank you for the quick fix! Is this something that would make sense to backport to 24, so people using the upcoming 24.0.0 don't hit this issue?
10-02-2025

Changeset: 1ab1c1d5 Branch: master Author: Liam Miller-Cushon <cushon@openjdk.org> Date: 2025-02-06 17:33:44 +0000 URL: https://git.openjdk.org/jdk/commit/1ab1c1d53b86228be85aac96fa5d69db39ac6317
06-02-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23448 Date: 2025-02-04 19:48:55 +0000
04-02-2025

Thanks for the report. The change in JDK-8332744 means that sunapi diagnostics are consistently emitted when system APIs are being resolved from --system, and not from ct.sym. Previously they were being read from ct.sym, so passing -XDignore.symbol.file disabled the diagnostics because of that bug. I don't think that -XDignore.symbol.file was ever intended as a suppression mechanism for sunapi diagnostics. There used to be an internal flag '-XDenableSunApiLintControl' to enable using -Xlint to control them, but it was removed (https://bugs.openjdk.org/browse/JDK-8148808). I'm not sure what the full history of that is or if there's a possibility of re-enabling -Xlint control for these. I agree there is a useability issue with -Werror for diagnostics that are not suppressible or controllable with -Xlint. re: deprecation, several methods in sun.misc.Unsafe are deprecated-for-removal by JEP 498, but not all of them and not the enclosing class. So there's overlap but there are places that sunapi would report that deprecation doesn't.
31-01-2025

Thank you for the background explanation. > I don't think that -XDignore.symbol.file was ever intended as a suppression mechanism for sunapi diagnostics. I don't know the history, but it seems [widely used](https://github.com/search?q=%22-XDignore.symbol.file%22&type=code) AFAIK mostly (only?) as a way to disable these internal proprietary API warnings. It's certainly a weird name for it and a more explicit flag would be a clearer way to disable these warnings. Could these warnings be given a -Xlint category? Then e.g. -Xlint:all,-sun would suppress/control them. That would solve this issue nicely.
31-01-2025