> On 28 Oct 2015, at 20:55, Chris Hegarty 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/
>
+1
Paul.
> This will be pu
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 dow
On 29/10/2015 14:12, Chris Hegarty wrote:
:
Yes, good point. I updated just the corba webrev.
http://cr.openjdk.java.net/~chegar/8140606/01/corba/
I’ll be tackling ManageLocalsThread separately in the near
future so have done just the minimum in corba for now.
This looks good to me.
-Al
On 28 Oct 2015, at 21:42, Martin Buchholz 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
On 28 Oct 2015, at 22:14, Alan Bateman wrote:
> On 28/10/2015 19:55, Chris Hegarty 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/
> On Oct 28, 2015, at 12:55 PM, Chris Hegarty 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 change looks fine to m
On 28/10/2015 19:55, Chris Hegarty 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
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
lo
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://bu