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

[Mohan Radhakrishnan]

How could developers who are not in London and can't participate in
hackdays understand Jigsaw and test it ? Is there anything to add to the
Gitbook about Jigsaw ?

Thanks,
Mohan

On Mon, Jun 29, 2015 at 10:28 PM, Mandy Chung <mandy.chung at oracle.com>
wrote:

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