RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more
peter.levart at gmail.com
Wed Apr 6 06:43:43 UTC 2016
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
>> 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:
> ...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.
More information about the core-libs-dev