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

[Scott Stark]

It came up at the Java EC level that there was not going to be a public replacement. Hence, there was a concern raised and the OpenJDK teams have most recently replied with a new JEP that is addressing this issue.
http://openjdk.java.net/jeps/260 (JEP 260: Encapsulate Most Internal APIs)

Not every usage from Unsafe has a targeted public replacement, but they are asking for feedback on whether what is being targeted is sufficient.

----- Original Message -----
From: "Andrig T. Miller" <anmiller at redhat.com>
To: "Scott Stark" <sstark at redhat.com>
Cc: wildfly-dev at lists.jboss.org
Sent: Thursday, August 6, 2015 12:05:44 PM
Subject: Re: [wildfly-dev] sun.misc.Unsafe usage, etc.

My understanding was JDK9 was going to have a public API that replaces Unsafe.  It has been discussed on the concurrency interest list a number of times.  Is that not the case anymore?

Andy

----- Original Message -----
> From: "Scott Stark" <sstark at redhat.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Tuesday, July 21, 2015 11: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
>