RFR 9: 8138696 : java.lang.ref.Cleaner (original) (raw)

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

Mandy Chung mandy.chung at oracle.com
Tue Oct 13 01:12:26 UTC 2015

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

More information about the core-libs-dev mailing list