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

[Richard Warburton]

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
>
>