Alternative to sun.misc.Signal

Question

I started research to find an alternative to the sun.misc.Signal class, because it could be unsupported in upcoming JDKs (we're currently working on 1.6). When I build the project I get:

warning: sun.misc.SignalHandler is Sun proprietary API and may be removed in a future release

I came across multiple solutions but they don't fit my project e.g. in this question.

This is unacceptable in my situation because:

• Signals are used not only for killing application
• The application is huge - every conceptual change of communication between modules/JVMs could take years to implement

Thus, the desirable solution is to find something like a new Oracle version of this class or something which works in the same way. Does such a solution exist?

Solution 1

As you will find repeated ad infinitum when learning about signal handling in Java, you are encouraged to avoid writing Java code that depends directly on signals. The general best practice is to allow the JVM to exit normally on ctrl+c and other signals by registering a shutdown hook instead. Handling signals directly makes your Java program OS-dependent.

But sometimes that's OK, and you really, really do want to handle signals yourself.

Even though it's not exposed as part of the official JDK API, some part of the JVM has to handle signals (in order to trigger the shutdown hooks and exit), and that component is sun.misc.Signal. Although this is an implementation detail and therefore could change, it is unlikely in practice. If it were to change, it would need to be replaced with an equivalent mechanism, and likely documented in the Java Platform Troubleshooting Guide.

The sibling class sun.misc.Unsafe is widely used and is similarly undocumented. There is active work towards trying to remove this class because it's "become a 'dumping ground' for non-standard, yet necessary, methods", but the current proposal, while limiting some non-standard APIs, keeps both sun.misc.Unsafe and sun.misc.Signal available by default. An earlier plan to actually prevent access to these classes would still have included a command-line flag to allow access to them for backwards-compatibility.

In short while you cannot rely on sun.misc.Signal and must plan for the eventuality that this behavior changes, it is highly unlikely that this behavior will change before JDK 10, and if it does either a new, better mechanism will probably be introduced or there will be a reasonable way to re-enable it if needed.

However it would be wise to compartmentalize the code that relies on any sun.misc classes to as small a scope as possible - create a wrapping API for signal handling so that callers don't need to interact directly with sun.misc. That way if the API changes you only need to change the implementation of your wrapper, rather than all your signal handling code.

Solution 2

If you can not accept any possibility that sun.misc.Signal might change in the recent future then just implement the signal handling yourself, with the JNI interface, in a language that compiles to machine code (like C) and import the library with System.load. Using JNI, java can use C and C can use java. The first time I used JNI I found it amusing to have the ability to use the whole java api from within my C program.

Now the only thing you have to worry about is if the OS interface will change or, far more likely, that the choice of OS in use will change.

Solution 3

Such a solution does exist. JNR ( https://github.com/jnr/ ) is an efficient POSIX layer; comparison with JNI+JNA I read here: https://www.slideshare.net/skrb/jnr-java-native-runtime .

This is my code to handle SIGHUP in Java using JNR:

SignalHandler handler = new SignalHandler()
    {
    @Override public void handle(int signal)  { reloadThings(); }
    };
final POSIX posix = POSIXFactory.getPOSIX(new DefaultPOSIXHandler(), true);
posix.signal(Signal.SIGHUP, handler);

The SignalHandler code is what will be done, the posix Handle is the JNR entry point AFAIK, and then the last line registers the signal.

JNR seems to be under active development (as of 2021), and isn't too large. Looks good to me - I just started using it because of this. PS: I just checked this to work with SIGINT = Ctrl+C. It does.

Comments

[a_horse_with_no_name]

None of those alternatives can be used to e.g. handle a SIGTERM (Ctrl-C) in a console application

[Ar5hv1r]

@specializt care to share a citation or reference? It's still in the head revision of JDK 8 and JEP 260 still indicates sun.misc.{Signal,SignalHandler} will "remain accessible in JDK 9". Even if the plan for JDK 9 had changed it would be very strange at this point for them to remove it from the already- released JDK 8.

[nerdherd]

Update - sun.misc.Signal is alive and well in JDK 11, and I can't find anything indicating any current plans for removal.

[josemmo]

Another update: sun.misc.Signal is still available in JDK 16

[Torsten Römer]

Very nice, just add one dependency com.github.jnr:jnr-posix and copy your snippet and it works. Just for CTRL+C/SIGINT, I had to set useNativePOSIX of POSIXFactory#getPOSIX to false, at least on Linux, otherwise the signal was trapped but the handler not executed.