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
