RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

[Roger Riggs]

Hi,

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

Roger


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 
>>> determining
>>> 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.
>
> -Alan