[wildfly-dev] sun.misc.Unsafe usage, etc.

[Anil Saldanha]

Totally agree with both of you.
The reason a discussion on Unsafe is happening after all these years
implies that a lot of projects have used it over the years and there is no
way to completely shield it. Definitely some mechanism have to be put in
place in the JDK to provide hooks to developers who need it.
Remember, the setAccessible(true) for private fields? The existence of this
mechanism helps when you need it.

On Wed, Jul 22, 2015 at 12:15 PM, Jason Greene <jason.greene at redhat.com>
wrote:

> Yes thats exactly what I mean. These low level hooks have been a boon to
> innovation, and it would be a shame to stifle that. I am sympathetic to
> their desire to not provide compatibility guarantees around these methods,
> and to hide them by default. So if they go the route of a flag or a special
> module import/permission I think thats reasonable and accomplishes that
> goal. I am more worried about them being outright prevented and unreachable.
>
> > On Jul 22, 2015, at 11:27 AM, Scott Stark <sstark at redhat.com> wrote:
> >
> > Your talking about why we need to still have a push for the features of
> Unsafe to be exposed in the jdk to allow for innovation? Agreed about that.
> >
> > ----- Original Message -----
> > From: "Jason Greene" <jason.greene at redhat.com>
> > To: "Scott Stark" <sstark at redhat.com>
> > Cc: wildfly-dev at lists.jboss.org
> > Sent: Tuesday, July 21, 2015 2:01:45 PM
> > Subject: Re: [wildfly-dev] sun.misc.Unsafe usage, etc.
> >
> > Right, it effectively locks us out of creating either derivatives or
> backports of java.util.concurrent, which is an active project that moves
> along independently of the JDK, leaving it continually behind. So its still
> a problem after JDK8. There are ways around it, in that you can port them
> in many cases to using AtomicXXX or AtomicXXXReferenceFieldUpdater.
> However, these are currently slower.
> >
> >> On Jul 21, 2015, at 3:44 PM, Scott Stark <sstark at redhat.com> wrote:
> >>
> >> One major usage jumping out is that of JSR166 java.util.concurrency
> class backports. These will be a non-issue once Java 8+ is a requirement.
> >>
> >> ----- Original Message -----
> >> From: "Scott Stark" <sstark at redhat.com>
> >> To: wildfly-dev at lists.jboss.org
> >> Sent: Tuesday, July 21, 2015 10:58:08 AM
> >> Subject: [wildfly-dev] sun.misc.Unsafe usage, etc.
> >>
> >> In case you didn't see the msg I sent to the core, I started up a
> discussion thread "What are our middleware sun.misc.Unsafe uses?" (
> https://developer.jboss.org/message/936359) to identify and track the
> replacement for all of the Unsafe uses. As the start of the discussion
> indicates, this came up because there was fear that Java 9 would prevent
> access to the various internal packages. There may be a Java EC working
> group on the problem, but it would be best for use to work on getting
> public replacements in place by working with our OpenJDK team lead by
> Andrew Haley.
> >>
> >> I have some comments I collected from other threads on the topic from
> Andrew, Jason and David as well as the Java EC summary of the Unsafe
> situation as background at the start of the thread.
> >>
> >> Please add to or correct anything that shows up on the thread as I work
> through the projects to identify what we are using and why.
> >>
> >> The first think I checked out was the use of the Unsafe usage by
> jboss-modules in the current wildfly trunk build. That turns out to be
> synchronization primitives that have already been dropped in the 1.5.0
> snapshot due to JDK7+ being required. Hopefully most of these are similar
> workarounds for older Java platforms, but where they are not, I want to
> make sure we are either tracking or creating an OpenJDK JEP (
> http://openjdk.java.net/jeps/1) for the public api replacement.
> >>
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> > --
> > Jason T. Greene
> > WildFly Lead / JBoss EAP Platform Architect
> > JBoss, a division of Red Hat
> >
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150722/925d5f62/attachment-0001.html