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

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

Remi Forax forax at univ-mlv.fr
Tue Oct 13 08:11:58 UTC 2015

Hi Roger,

I agree with comments from Mark and Mandy, you can also simplify your code by using a lambda instead of a class to implement the thread factory.

public static Cleaner create() { return create(runnable -> { return AccessController.doPrivileged((PrivilegedAction) () -> { Thread t = new InnocuousThread(runnable); t.setName("Cleaner-" + t.getId()); return t; }); }); }

given that the lambda (the one that takes a Runnable) doesn't capture anything, it will be considered as a constant by the VM, so no need to implement the singleton pattern, here.

cheers, Rémi

----- Mail original -----

De: "Mandy Chung" <mandy.chung at oracle.com> À: "mark reinhold" <mark.reinhold at oracle.com> Cc: core-libs-dev at openjdk.java.net Envoyé: Mardi 13 Octobre 2015 03:12:26 Objet: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> 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