RFR 9: 8087286 Need a way to handle control-C and possibly some other signals
roger.riggs at oracle.com
Mon Feb 8 18:48:38 UTC 2016
I would not (did not) see this as significant but given the discussion
I'll break it down into two independent updates:
1) for JEP 260, clone the s.m.Signal Api into a JDK internal package
for use with
java.lang.Terminator and jshell with s.m.Signal layered on top
that will end up
in the jdk.unsupported package
2) Work on more restrictive API later
On 2/8/16 5:06 AM, Alan Bateman wrote:
> On 08/02/2016 07:02, Stuart Marks wrote:
>> On 2/5/16 4:54 PM, David Holmes wrote:
>>> Regardless of whether I agree with this API or not, it does, as
>>> Stuart points
>>> out, require a JEP and to go through the normal rigorous process of
>>> whether an API is suitable for inclusion in the Java platform.
>> Note, it was Thomas Stüfe who suggested a JEP for this.
> It's a good question.
> It is an explicit non-goal of JEP 260 to propose replacements of
> internal APIs. Providing a standard API for handling control-C or OS
> signals is of course strongly connected with the efforts in JEP 260
> but isn't a goal.
> The JEP process provides guidelines as to when a JEP should be
> drafted. In this case it seems like the API is significant and that a
> JEP would make be very useful. If nothing else, the JEP could document
> alternatives considered, like for example a specific API for handling
> control-C/VM termination and other specific use-cases as opposed to
> exposing OS signals to applications.
More information about the core-libs-dev