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

[Remi Forax]

I see,
I have seen the lambda used by doPrivileged and stupidly thunk it will be Ok to encapulate it in another lambda but because there are not called at the same time, we can't do that.

cheers,
Rémi

----- Mail original -----
> De: "Roger Riggs" <Roger.Riggs at Oracle.com>
> À: core-libs-dev at openjdk.java.net
> Envoyé: Mardi 13 Octobre 2015 14:53:47
> Objet: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use	alternative to finalization
> 
> Hi Remi,
> 
> That was the initial implementation.  However, it was being invoked
> during startup before Lambda was initialized and resulted in an
> ExceptionInInitializer.
> 
> We don't have a good handle on when it is too early to use lambda except
> by trial and error.
> I think there are some improvements in the works so that some simple
> cases of Lambda
> can be used earlier and will see if they apply.
> 
> Thanks, Roger
> 
> 
> 
> On 10/13/2015 4:11 AM, Remi Forax wrote:
> > 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
> >>
> >>
> 
>