Hi Roger,
I think this is a good compromise. Having the low-level extended
functionality in the JDK for internal use until it is proven. Dropping
Cleanable.clear() is also a correct move. I currently don't see a use
for it. If one registers a cleaning function, why would one then try to
change his mind? It's better to decide upfront before registering. You
could make final clear() in XxxCleanable classes throw UOE like it's
done for get() in XxxCleanableRef. This way no Reference methods will be
usefully accessible from Cleanable instance that is given to users and
nobody will be tempted to cast it to Reference.
Regards, Peter
On 10/20/2015 08:28 PM, Roger Riggs wrote:
Sorry for the silence, JavaOne preparations and the availability of
folks who wanted
to review have stretched things out.
The Cleaner API was very simple and saw feature creep as the ideas for
how it might be used
were explored. There are concerns about committing to supporting
subclassable
CleanableReferences in all future JDK versions before there had been a
chance to
see how if they would be useful and necessary to address the need to
reduce the
use of finalization within the OpenJDK and beyond.
Recent updates:
- The Cleaner implementation classes and the CleanableReference
abstract classes are
now in the jdk.internal.misc package and are available within the
java.base module.
- The Cleanable.clear method has been dropped; there is no current
use case.
Since the CleanableReferences extend Reference, clear() is
available when subclassing.
- The tests have been extended to cover the exported and internal APIs
The Runnable thunk version is very convenient to code but does
transparently create
an additional object to hold the bindings.
As the Cleaner is applied to the various uses of finalize we'll see
how they would be used
and can re-evaluate the exported API needs.
Updated Javadoc:
http://cr.openjdk.java.net/~rriggs/cleaner-doc/
Updated Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/
Thanks, Roger
