RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

[Uwe Schindler]

Hi,

API changes l and security check look good to me. I don't have time to compile and test a JDK, but I trust you that it works :-)

Uwe

-----
Uwe Schindler
uschindler at apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: Tuesday, January 26, 2016 5:28 PM
> To: Alan Bateman <Alan.Bateman at oracle.com>; Roger Riggs
> <roger.riggs at oracle.com>; uschindler at apache.org
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref
> 
> Latest webrev updated in-place:
>   http://cr.openjdk.java.net/~chegar/8148117/
> 
>  * to execute the run method requires an appropriate permission
>  * reverted any copyright changes ( leave to a bulk update )
>  * updated the test to remove the script
> 
> -Chris.
> 
> 
> On 26 Jan 2016, at 15:23, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> > On 26/01/2016 13:55, Chris Hegarty wrote:
> >> It is wonderful to see the various ideas on this thread about the longer
> >> term solution to the prompt releasing of direct buffer native memory. I
> >> do not want to obstruct that ( it is very informative ), but I’d like to warp
> up
> >> the review on the actual moving of Cleaner. To that end, I’ve update the
> >> webrev as per Alan’s comments and suggestion ( to extend Runnable ).
> >>
> >> http://cr.openjdk.java.net/~chegar/8148117/
> >>
> >> -Chris.
> >>
> >>
> > This looks okay. As a defensive-in-depth then Cleaner::run can do a
> permission check and should ease concerns about leakage.
>