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@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@redhat.com>
> To: "Scott Stark" <sstark@redhat.com>
> Cc: wildfly-dev@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@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@redhat.com>
>> To: wildfly-dev@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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev