There was some observation (in an off-line conversation) that since
this is being deprecated it is probably a bit late to start documenting
it with lots of advice along these and other lines ..
-phil.
On 03/31/2017 10:25 AM, Roger Riggs wrote:
Hi Hans,
Can you suggest how that would be expressed? The advice would seem to
have some complex conditions.
Would it be the case that a caller using a reference to any resource
held by a finalizable object
must use reachabilityFence to ensure that the resource can not be
cleaned up while it is planning to use the resource?
Is there a citation that can supply the context and background for a
warning or is the explanation
in reachabilityFence sufficient?
Roger
On 3/31/2017 1:05 PM, Hans Boehm wrote:
In my view, the primary reason to prefer Cleaner or PhantomReference
is safety (no accidental access to previously finalized objects,
which usually turn into dangling pointer dereferences with JNI).
Flexibility and efficiency also matter, but I would put them second
and third.
Can we add a warning that it is almost never safe to override
finalize() without use of reachabilityFence()?
On Fri, Mar 31, 2017 at 6:55 AM, Roger Riggs <roger.ri...@oracle.com
<mailto:roger.ri...@oracle.com>> wrote:
The webrev for deprecating finalize has been updated:
- to improve the advice existing JDK subclasses overriding
finalize provides in @deprecated javadoc,
- to expand Object.finalize() javadoc to reinforce the correct
use of super.finalize() by subclasses,
- and to remove redundant @SuppressWarnings annotations.
Please review and comment.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641/
<http://cr.openjdk.java.net/%7Erriggs/webrev-finalize-deprecate-8165641/>
Issue:
https://bugs.openjdk.java.net/browse/JDK-8165641
<https://bugs.openjdk.java.net/browse/JDK-8165641>
Thanks, Roger
