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.hol...@oracle.com
<mailto:david.hol...@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/
<http://cr.openjdk.java.net/%7Erriggs/webrev-cleaner-8138696/>
[2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html
<http://cr.openjdk.java.net/%7Erriggs/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
