Hi Peter,
Since the current implementation of the old Cleaner and DirectByteBuffer
works well and there is a
lot of work piling up against the FC date, I'm in favor of keeping it as
it is until the possibilities
with Panama settle out. It would best if reclamation was not GC based,
except as a last resort.
As for the Cleaner API, it is intended to have a specific function and API.
It may be that there is some advantage/optimization in the cleaner
implementation
at some future point but the API for general use should be concrete and
specific.
For more specific purposes, especially internal ones like the topic
here, separate factory methods
would be more appropriate than potential overloading and mix-in interfaces.
Roger
On 4/6/2016 2:43 AM, Peter Levart wrote:
Hi Roger,
On 04/05/2016 04:41 PM, Peter Levart wrote:
On 04/04/2016 11:50 PM, Roger Riggs wrote:
I don't see the need to change Cleaner to an interface to be able to
provide
an additional method on CleanerImpl or a subclass and a factory
method could
provide for a clean and very targeted interface to Bits/Direct buffer.
I would like this to be an instance method so it would naturally
pertain to a particular Cleaner instance. Or it could be a static
method that takes a Cleaner instance. One of my previous webrevs did
have such method on the CleanerImpl, but I was advised to move it to
Cleaner as a package-private method and expose it via SharedSecrets
to internal code. I feel such "camouflage" is very awkward now that
we have modules and other mechanisms exist. So I thought it would be
most elegant to make Cleaner an interface so it can be extended with
an internal interface to communicate intent in a type-safe and
auto-discoverable way. The change to make it interface:
http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.part2.1.rev01/
...actually simplifies implementation (33 lines removed in total) and
could be seen as an improvement in itself.
Are you afraid that if Cleaner was an interface, others would attempt
to make implementations of it? Now that we have default methods on
interfaces it is easy to compatibly extend the API even if it is an
interface so that no 3rd party implementations are immediately
broken. Are you thinking of security implications when some code is
handed a Cleaner instance that it doesn't trust? I don't think there
is a utility for Cleaner instances to be passed from untrusted to
trusted code, do you?
...even if we don't do anything for DirectByteBuffer(s) in
java.lang.ref.Cleaner and leave things as they stand (using
jdk.internal.ref.Cleaner), I would still make this transition to
interface to enable possible future internal extensions to
java.lang.ref.Cleaner. As I said, this is a source compatible change,
but not binary compatible, so if we do it, it must be performed before
JDK 9 ships.
Regards, Peter
