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

[Remi Forax]

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>) () -> {
        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
> 
>