RFR 9: 8087286 Need a way to handle control-C and possibly some other signals
chris.hegarty at oracle.com
Mon Feb 8 09:16:54 UTC 2016
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
- 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  , 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.
More information about the hotspot-runtime-dev