RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

[Roger Riggs]

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
>