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

[Paul Benedict]

No, you didn't miss any. I didn't know you were using line breaks for
readability or meant a new paragraph. No worries. You are right they don't
break the paragraph in javadoc.

Cheers,
Paul

On Tue, Dec 15, 2015 at 10:00 AM, Roger Riggs <Roger.Riggs at oracle.com>
wrote:

> Hi Paul,
>
> The credit/blame for the Cleaner doc is mine.
>
> On 12/15/2015 10:25 AM, Paul Benedict wrote:
>
> David, this needs editing.
>
> * The cleaning function is invoked after the object it is cleaning up
> after it
> * becomes phantom reachable, so it is important that the references and
> values
> * it needs do not prevent the object from becoming phantom reachable.
>
> 1) The "after it" looks like a leftover from an edit
> 2) "becomes phantom reachable" after already "becoming phantom reachable"
> needs clarification to make sense:
>
> Yes, this poorly worded.  It has been simplified in the latest update.
>
>
> My suggestion:
>
> * The cleaning function is invoked after the object it is cleaning becomes
> * phantom reachable, so it is important that the object's references and
> values
> * do not prevent the object from remaining phantom reachable.
>
> PS: I noticed in the source that much of the documentation is written with
> line breaks but without the <p> tag. If you have a paragraph in mind,
> perhaps you can remove the line breaks so it doesn't look like <p> tags
> were meant to be there but forgotten.
>
> Blank lines improve readability of the source; but should not appear to
> break any paragraph.
> Did I miss some?
>
> Thanks, Roger
>
>
>
> Cheers,
> Paul
>
> On Tue, Dec 15, 2015 at 1:01 AM, David Holmes < <david.holmes at oracle.com>
> david.holmes at oracle.com> wrote:
>
>> PS.
>>
>> create(): can also throw SecurityException if not allowed to create/start
>> threads.
>>
>> David
>>
>> On 10/12/2015 4:40 AM, 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
>>>>>>
>>>>>>
>>>>
>>>
>
>