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

Roger Riggs 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 
>>> 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

More information about the core-libs-dev mailing list