Jigsaw Hackday in London - Anything in particular you want us to look at?
Mani Sarkar
sadhak001 at gmail.com
Tue Jul 21 21:45:55 UTC 2015
All resources will surely find its way into the gitbook and the respective
wikis,
Cheers,
Mani
On Tue, Jul 21, 2015 at 7:30 AM, Martijn Verburg <martijnverburg at gmail.com>
wrote:
> We'll publish the hackday materials to Github so others can follow along.
>
> Cheers,
> Martijn
>
> On 21 July 2015 at 05:43, Mohan Radhakrishnan <
> radhakrishnan.mohan at gmail.com
> > wrote:
>
> > 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
> > > >>
> > > >>
> > >
> > >
> >
>
--
@theNeomatrix369 <http://twitter.com/theNeomatrix369>* | **Blog
<http://neomatrix369.wordpress.com>** | *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>* | **Bitbucket
<https://bitbucket.org/neomatrix369>* * | **Github
<https://github.com/neomatrix369>* * | **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/
*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*
More information about the adoption-discuss
mailing list