RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Roger Riggs Roger.Riggs at Oracle.com
Wed Dec 2 20:23:49 UTC 2015


Please review the java.lang.ref.Cleaner and tests following the 
recommendation to simplify the public
interface to support only phantom cleanup.

Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/

Javadoc:
    http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html

Thanks, Roger


On 11/23/2015 5:32 PM, mark.reinhold at oracle.com wrote:
> ( Finally getting back to this, after too many weeks of travel ... )
>
> 2015/10/20 11:28 -0700, roger.riggs at oracle.com:
>> Sorry for the silence, JavaOne preparations and the availability of
>> folks who wanted to review have stretched things out.
>>
>> The Cleaner API was very simple and saw feature creep as the ideas for
>> how it might be used were explored.  There are concerns about
>> committing to supporting subclassable CleanableReferences in all
>> future JDK versions before there had been a chance to see how if they
>> would be useful and necessary to address the need to reduce the use of
>> finalization within the OpenJDK and beyond.
>>
>> ...
>>
>> Updated Javadoc:
>>     http://cr.openjdk.java.net/~rriggs/cleaner-doc/
>>
>> Updated Webrev:
>>      http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/
> I'm very happy to see this API return to something like its original
> simple form, but I think it can be simplified even further.
>
> We have a very strong need for phantom-ref-based cleaners, so as to
> discourage people from relying upon flaky finalization. The arguments in
> support of the weak and soft forms have, by contrast, been rather weak
> (and soft?).  I don't think it's right to bake methods into a core API
> based on just a couple of hypothetical use cases.  I'd much rather see
> the Cleaner::{phantom,soft,weak}Cleanable methods reduced to a single
> register method,
>
>      Cleaner.Cleanable register(Object, Runnable);
>
> which would create the phantom form only.  If strong justification for
> the other forms arise then we can generalize this later, either to
> distinct register{Soft,Weak} methods or, perhaps, to a method that takes
> a type token.
>
> - Mark




More information about the core-libs-dev mailing list