Using this small reproducer:
```java
import sun.misc.Signal;

public class MyLibraryWithSignal {

    public static void main(String[] args) throws InterruptedException {
        Signal.handle(new Signal("INT"), signal -> {
            // Imagine some more useful signal handler, just keeping the example short here
            System.out.println("Goodbye!");
            System.exit(0);
        });

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

}
```

Compiling it with javac gives:
```
$ javac -Xlint:all MyLibraryWithSignal.java
MyLibraryWithSignal.java:1: warning: Signal is internal proprietary API and may be removed in a future release
import sun.misc.Signal;
               ^
MyLibraryWithSignal.java:6: warning: Signal is internal proprietary API and may be removed in a future release
        Signal.handle(new Signal("INT"), signal -> {
                          ^
MyLibraryWithSignal.java:6: warning: Signal is internal proprietary API and may be removed in a future release
        Signal.handle(new Signal("INT"), signal -> {
        ^
warning: Signal is internal proprietary API and may be removed in a future release
4 warnings
```

The principle of warnings is for them to be actionable, to tell people seeing them to do something about it.

But what can a user using sun.misc.Signal do?
* They cannot just stop using it, that breaks useful functionality. There is no replacement API that can be used instead.
* Being the only Java API available to use signals it is the one used by many projects. The fact it's under `sun.misc` is basically just legacy. It cannot be called "internal proprietary API" given the usage of it today (by many projects and being supported even on non-HotSpot).
* sun.misc.Signal is widely used, e.g. https://github.com/search?q=sun.misc.Signal&type=code
* The warning cannot be suppressed as far as I can tell. -XDignore.symbol.file used to suppress it, but no longer has that effect. This got addressed JDK-8349058, but still the problem is there: there is a warning which the user cannot do anything about except suppressing it, i.e. it cannot be addressed.
* Asking each Java project to reimplement Signal with JNI (far from trivial, need to ship a native library, can lead to subtle bugs in interactions with how the JDK uses signals) seems unreasonable and in fact running against the goals of integrity by default.

Is therefore the only way to address these warnings to use jdk.internal.misc.Signal instead? I would think that's not a good solution.

I think these warnings for sun.misc.Signal should be removed (nothing can be done about them), warnings should be added when a replacement is available, something like java.util.Signal or so.