Here's the plan: - There will be an upcoming "round two" of jsr166 integration, focusing on jtreg tests. - We already need to massage jsr166 sources for integration, and adjusting sun.misc.Unsafe to the new blessed name is relatively trivial. - (There will be confusion and resistance to locking down Unsafe. I wouldn't be surprised if future users built their own jdk just to expose Unsafe functionality.)
On Thu, Oct 29, 2015 at 7:12 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: > > On 28 Oct 2015, at 21:42, Martin Buchholz <marti...@google.com> wrote: > > > This will cause jsr166 CVS code to no longer be able to run on jdk8, as > it does today. We will probably need to fork soon anyways due to Paul's > VarHandle code, but we had not expected it to be necessary before then. Is > there any easy way for jsr166 CVS src/main to remain "portable" for a while > longer? Alternatively, what can we do to continue using "good old > sun.misc.Unsafe" in jsr166 CVS? > > Right, for now I think you can continue to use sun.misc.Unsafe, > until VarHandles arrive. Since the major 166 sync is done, the > amount of change in this area should be small. I can help out > with incoming changes also, until you fork. > > -Chris. > > > On Wed, Oct 28, 2015 at 12:55 PM, Chris Hegarty < > chris.hega...@oracle.com> wrote: > > Following on from 8139891 "Prepare Unsafe for true encapsulation” [1], > > the JDK library code should use the internal Unsafe class, and not > > sun.misc.Unsafe. > > > > http://cr.openjdk.java.net/~chegar/8140606/00/ > > > > This will be pushed to jdk9/dev once 8139891 makes its way from > > hs-rt. > > > > -Chris. > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8139891 > > > >
