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

[Peter Levart]

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