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

[Chris Hegarty]

On 8 Feb 2016, at 07:02, Stuart Marks <stuart.marks at oracle.com> 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.

Here is my take on the situation:

 - The proposal appears to be a relatively small API, and, in my opinion,
   does not meet any of the criteria to be considered under the JEP
   process.

 - The proposal is for a low-level API. It is not expected to be widely
   used. Maybe a less prominent position in the package hierarchy
   would be less offensive?

 - This is not strictly JEP 260 related, but the proposal has been, 
   somewhat, motivated by the fact that 260 will have to make changes
   in this area.  ( Roger has already proven in his webrevs that sun.misc
   Signal can be implemented by a purely private signal implementation )

 - I would ague that this proposed API is in the spirit of Java ( Java-like ),
   since a Java process may be able send a signal, through the process
   API [1] , and then handle that signal through this API.  It is safe ( does
   NOT crash) , implementable ( best-effort on different platforms ).
   Accepting the platform limitations, it is still possible that one Java
   process can send a signal to another Java process, on the same
   system. This seems useful.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-4914493