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