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 uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Chris Hegarty [mailto:chris.hega...@oracle.com] > Sent: Tuesday, January 26, 2016 5:28 PM > To: Alan Bateman <alan.bate...@oracle.com>; Roger Riggs > <roger.ri...@oracle.com>; uschind...@apache.org > Cc: core-libs-dev <core-libs-dev@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.bate...@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. >
