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

Peter Levart peter.levart at gmail.com
Wed Feb 17 16:16:23 UTC 2016

On 02/17/2016 10:06 AM, Peter Levart wrote:
     On 02/17/2016 01:20 AM, Kim Barrett wrote:
>> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java
>> I don't understand why CleanerImpl needs to be changed to public in
>> order to provide access to the new drainQueue. Wouldn't it be better
>> to add Cleaner.drainQueue?
> An interesting idea. But I don't know if such functionality is 
> generally useful enough to commit to it in a public API.
> I have another idea where java.lang.ref.Cleaner would use an Executor 
> instead of ThreadFactory. The default would be an instance of a 
> single-threaded executor per Cleaner instance, but if user passed in a 
> ForkJoinPool, he could use it's method ForkJoinPool.awaitQuiescence() 
> to help the executor's thread(s) do the cleaning. 

...well, this would not be a good idea as ReferenceHandler thread would 
then have to feed the Executor (invoke Executor::execute(Runnable)) and 
a user-specified Executor could abuse that. There has to be a queue API 
between ReferenceHandler and custom user code.

Regards, Peter

More information about the core-libs-dev mailing list