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

[Chris Hegarty]

Uwe,

On 28 Jan 2016, at 11:28, Uwe Schindler <uschindler at apache.org> wrote:

> Hi,
> 
> Could you update the JIRA issue (https://bugs.openjdk.java.net/browse/JDK-8132928) and JEP 260 (http://openjdk.java.net/jeps/260) about the change we discussed here (jdk.internal.ref.Cleaner now implements Runable to support Lucene and similar apps needing to hack into cleaner), mainly in the section "open issues”?

You are still in unsupported waters. You are using reflection and setAccessible(true)
to gain access to the internals of direct buffer. The refactoring we are doing in
Cleaner as part of this issue, has a positive side-effect, from a library maintainers
point of view ( less reflective code and static usage of internal types), but this is not
to be confused with an agreed upon supported interface. It is just to keep things
working, as we refactor / move some internal types in the JDK. Longer term a
standard Java SE API should replace this.

JEP 260 will, for the present time, continue to list sun.misc.Cleaner as an open
issue, until we are satisfied that there is no critical need for it, outside of the 
direct/mapped buffer usage.

> Maybe also add a comment to the source at the "@Override public void run()" decl, so it may not get lost by later refactorings (if somebody thinks "WTF!?")
> 
> The update of above docs would be fine for us to have some reference point to cite when we implement the changed Hack. BTW, we already have a preliminary patch for Lucene (untested): https://issues.apache.org/jira/secure/attachment/12784516/LUCENE-6989.patch

Thanks for doing this Uwe.  I really appreciate your feedback and prompt
replies on this topic.

-Chris.

> Thanks for taking care of this issue.
> Uwe
> 
> -----
> Uwe Schindler
> uschindler at apache.org 
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
> 
>> -----Original Message-----
>> From: Uwe Schindler [mailto:uschindler at apache.org]
>> Sent: Tuesday, January 26, 2016 5:49 PM
>> To: 'Chris Hegarty' <chris.hegarty at oracle.com>; '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
>> 
>> 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.
>>> 
> 
>