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
