JDK-8087286 : Need a way to handle control-C and possibly some other signals
  • Type: Enhancement
  • Component: core-libs
  • Affected Version: 9
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2015-06-11
  • Updated: 2025-02-19
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
Duplicate :  
JDK-8349056 - internal proprietary API warnings for sun.misc.Signal are not actionable
Relates :  
JDK-8295702 - Signal.handle can't correctly restore all signal handlers on Posix systems
Relates :  
JDK-6423780 - (process) need way to handle OS signals
Relates :  
JDK-4914493 - (process) Cannot send arbitary signals to UNIX process
Relates :  
JDK-8349056 - internal proprietary API warnings for sun.misc.Signal are not actionable
Relates :  
JDK-8137055 - Prepare for JEP 260
Description
Catching control-C and possibly other signals is one way for applications to handle user-interrupted action.  

There is currently no supported API to intercept and handle any signal.  sun.misc.Signal and sun.misc.SignalHandler are internal API that some existing application depends on.

Need to look into a possible replacement for sun.misc.Signal and SignalHandler API.
Comments
All the usual criteria required for a full-fledged JDK API. Well-specified, cross-platform, robust implementation, benefits vastly outweigh costs, ...
19-02-2025
> Moving the existing sun.misc.Signal class to java.util is not viable as the existing unsupported API does not meet the criteria for being a supported API. Which criteria specifically?
18-02-2025
The "blocker" is that demand is actually very low; defining a supported, cross-platform, signal handling API with well-defined semantics is very hard; and a workaround exists through sun.misc.Signal or JNI (and now FFM?). Moving the existing sun.misc.Signal class to java.util is not viable as the existing unsupported API does not meet the criteria for being a supported API.
18-02-2025
From https://github.com/search?q=sun.misc.Signal&type=code it is clear sun.misc.Signal is widely used, there is no question a replacement is needed before sun.misc.Signal can be phased out. I think the replacement could be just moving sun.misc.Signal to a more appropriate package, like java.util.Signal. The path forward seems clear, what is the blocker for this? Until a replacement is provided, sun API warnings are emitted, even though the user cannot really address them if they need signals. Those warnings can be suppressed with -XDignore.symbol.file but that has other undesirable side effects (e.g. not using the symbol file and so missing the source is using methods not available in the target JDK). JDK-8349848 might address that part.
17-02-2025
The problem as always with these things is discerning a signal that was directed at the application versus a signal that was directed at the VM. Taking over ctrl-C can leave the VM unable to be terminated (with ease, or non-abruptly)
30-06-2015
SIGTRAP was mentioned also: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-June/004362.html
29-06-2015
A little personal feedback on how useful this is: I used the SignalHandler to recognise control C in a console application - the kjdb debugger tool - to let you terminate a long-running command (like getting all backtraces in all theads) that runs longer than you'd like. I just had the handler set a flag which the tool can check. The area of writing a console app is fairly neglected in Java, but that may be justifiable based on demand. After avoiding a termination due to an accidental (instinctive) control-C, the main frustration is using System.in to read user input. I did write a little library using JNI to read the terminal directly, to give a very "lite" emacs mode with ^P and ^N for history recall, and ^B and ^F to move forward within the edited line. I had ideas of implementing some other terminal capabilities, like knowing how wide the term window was so the tool could format appropriately, but haven't used that yet. On Windows, reading System.in gives you this for free in the command prompt.
12-06-2015