Jigsaw Hackday in London - Anything in particular you want us to look at?

[Mandy Chung]

FYI.  The RFE concerning sun.misc.SignalHandler is:
    https://bugs.openjdk.java.net/browse/JDK-8087286

Mandy

> On Jun 29, 2015, at 5:43 AM, Richard Warburton <richard.warburton at gmail.com> wrote:
> 
> Hi,
> 
> This is a good point actually. I have also used that class before as it
> seems to be the only way to hook those signals in a commandline app.
> 
> I appreciate its a difficult case to deal with since you cant safely run
> Java code inside a signal handler callback because signal handler callback
> code must be reentrant safe but it feels like having some kind of Java
> level hook for this kind of signal would be useful. Even if it is
> asynchronous.
> 
> regards,
> 
>  Richard
> On 29 Jun 2015 12:15, "Tglman" <tglman at tglman.com> wrote:
> 
>> Hi All,
>> 
>> I am a library developer, and in some cases in the project i work on is
>> used Unsafe, and we already planning to replace it with other solutions.
>> anyway while i was trying to test my project on jdk9 i found that also
>> other api we use are removed.
>> In my spefic case we use also 'sun.misc.SignalHandler', is this api
>> going to be available in future following the same approach used for
>> sun.misc.Unsafe ?
>> 
>> Is it there any replacement for handling not shutdown/kill/interrupt
>> signals ?
>> (In my specific case we catch also SIGTRAP)
>> 
>> Thank You
>> 
>> Emanuele
>> 
>> 
>> 
>> 
>> On 23/06/15 17:12, mark.reinhold at oracle.com wrote:
>>> 2015/6/23 8:45 -0700, vitalyd at gmail.com:
>>>> Yes, but until all the "safe" replacements are in place and vetted (e.g.
>>>> performance is on par with Unsafe, same functionality is available,
>> etc), I
>>>> don't see the point of making it even more annoying to grab hold of.
>> The
>>>> people who are using it will continue using it until the replacements
>> are
>>>> available, and this is just going to annoy them.
>>> That's precisely the point.
>>> 
>>> sun.misc.Unsafe and its ilk will go away one day.  In preparation for
>>> that, making it a bit harder to use will motivate its current users to
>>> consider whether they really do need to use it -- some do, but some
>>> don't.
>>> 
>>> If you absolutely do need it then now is the time to start looking at
>>> the alternatives in development, and contribute to those efforts in
>>> order to make sure that your needs are met.  Paul's work on variable
>>> handles (JEP 193 [1]), e.g., is far enough along that feedback would
>>> be useful.
>>> 
>>> Making sun.misc.Unsafe harder to use will also help the many users who
>>> unknowingly depend upon this unsupported API, via libraries which do
>>> depend upon it, to become aware of that dependence.  They can then
>>> either seek alternatives or ask the maintainers of those libraries to
>>> do so.
>>> 
>>> - Mark
>>> 
>>> 
>>> [1] http://openjdk.java.net/jeps/193
>> 
>>