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

[Mandy Chung]

> On Oct 12, 2015, at 12:30 PM, mark.reinhold at oracle.com wrote:
> 
> 2015/10/8 1:41 -0700, roger.riggs at oracle.com:
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-extensible-8138696/
>> 
>> javadoc:
>>    http://cr.openjdk.java.net/~rriggs/cleaner-doc2/
> 
> Roger -- thanks for taking this on.  The more we can do to get people
> to stop using sun.misc APIs, the better.
> 
> A couple of comments/questions:
> 
> First, I think the approach in your first version is, well, cleaner.

+1

I started reviewing the first version and pondering on the benefits of the new versions.


> The additional abstract classes in the second version look like a
> classic case of implementation inheritance that's not subtype
> inheritance, what with the overrides of the original enqueue and
> isEnqueued methods to throw UnsupportedOperationException.
> 
> I understand the desire to avoid allocating too many objects, but
> do we have actual use cases where that's critical?  The original
> sun.misc.Cleaner has been used by both internal and external code
> to do relatively heavy-weight things like unmap direct buffers and
> release other kinds of native resources, which suggests that
> allocating three small objects per cleaner is not a problem.
> 
> Second, the original sun.misc.Cleaner only handles phantom references.
> What are the use cases for weak and soft cleaners?
> 
> Finally, how important is it to be able to unregister a cleaner?  In
> all the years we've had sun.misc.Cleaner that capability has never
> been needed, and leaving it out would simplify the API.

If there is no strong need of unregister a cleaner, Cleaner API won’t need to return a Cleanable object which I think it’s nice and simpler. 

Mandy