RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

[Peter Levart]

Hi Roger,

Just one thing about implementation:

Since the type exposed to user is Cleaner.Cleanable that has only a 
single method clean(), it would be good if the implementation class 
(CleanerImpl.PhantomCleanableRef) overrode 
CleanerImpl.PhantomCleanable.clear() method and threw 
UnsupportedOperationException, otherwise users will be tempted to cast 
the returned Cleaner.Cleanable to Reference and invoke clear() method to 
de-register cleanup action without invoking it. This is the only 
remaining public Reference method that is not disabled this way.

Regards, Peter

On 12/09/2015 07:40 PM, Roger Riggs wrote:
> Hi,
>
> The example is revised to caution about inner classes and lambdas.
>
> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/
> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html
>
> Thanks, Roger
>
> On 12/9/2015 11:04 AM, Peter Levart wrote:
>> Hi Chris,
>>
>> On 12/09/2015 04:03 PM, Chris Hegarty wrote:
>>> Peter,
>>>
>>> On 09/12/15 07:05, Peter Levart wrote:
>>>> Hi,
>>>>
>>>> I think the only way to try to prevent such things is with a good
>>>> example in javadoc that "screams" of possible miss-usages.
>>>>
>>>>
>>>> public static class CleanerExample implements AutoCloseable {
>>>>
>>>>          private static final Cleaner cleaner = ...; // preferably a
>>>> shared cleaner
>>>>
>>>>          private final PrivateNativeResource pnr;
>>>>
>>>>          private final Cleaner.Cleanable cleanable;
>>>>
>>>>          public CleanerExample(args, ...) {
>>>>
>>>>              // prepare captured state as local vars...
>>>>              PrivateNativeResource _pnr = ...;
>>>>
>>>>              this.cleanable = cleaner.register(this, () -> {
>>>>                  // DON'T capture any instance fields with lambda 
>>>> since
>>>> that would
>>>>                  // capture 'this' and prevent it from becoming
>>>
>>> I assume that the WARNING should include anonymous inner classes too
>>> ( which I expect are quite common, though less now with lambda ) ?
>>>
>>> Is "leaking" 'this' in a constructor a potential issue with respect
>>> to the visibility of pnr? As well as causing red-squiggly lines in
>>> the IDE ;-)
>>
>> 'this' only leaks to the 'referent' field of PhantomReference where 
>> by definition is not accessible.
>>
>> 'this' can become phantom-reachable before CleanerExample constructor 
>> ends. But this is harmless, because the code that may execute at that 
>> time does not access the object any more, so the object may be safely 
>> collected.
>>
>> Cleanup action can run at any time after registration even before 
>> CleanerExample constructor ends. But this is harmless too, because it 
>> only accesses PrivateNativeResource which is fully constructed before 
>> registration of cleanup action.
>>
>> I see no issues apart from IDE(s) not seeing no issues.
>>
>> Regards, Peter
>>
>>>
>>> -Chris.
>>>
>>>
>>>> phantom-reachable!!!
>>>>                  _pnr.close();
>>>>              });
>>>>
>>>>              this.pnr = _pnr;
>>>>          }
>>>>
>>>>          public void close() {
>>>>              cleanable.clean();
>>>>          }
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>
>