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(a)redhat.com>
Yes thats exactly what I mean. These low level hooks have been a boon
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(a)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(a)redhat.com>
> To: "Scott Stark" <sstark(a)redhat.com>
> Cc: wildfly-dev(a)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(a)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(a)redhat.com>
>> To: wildfly-dev(a)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?" (
) 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
>> 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 (
) for the public api replacement.
>> wildfly-dev mailing list
>> wildfly-dev mailing list
> 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