RFR 9: 8165641 : Deprecate Object.finalize
Roger.Riggs at Oracle.com
Fri Mar 31 19:13:58 UTC 2017
On 3/31/2017 2:56 PM, Hans Boehm wrote:
> Agree entirely with Andrew's concern. I would mostly point to the
> java.lang.Reference documentation. One possible approach follows.
> Add the following to the apiNote. I would add it at the beginning,
> since I've rarely encountered the inheritance issues, and they're
> probably easier to debug:
> As with all reachability-based cleanup mechanisms, it is important to
> use java.lang.reReference.reachabilityFence to ensure that objects
> remain reachable while resources embedded in the object are in use.
Good suggestion for the Object.finalize deprecation doc, I'll see how to
work that in.
> However, looking at the reachabilityFence documentation, I think it's
> quite misleading, and greatly understates the need for using it. In
> particular the following paragraph seems most misleading:
> "This method is designed for use in uncommon situations of premature
> finalization where using synchronized blocks or methods, or using
> other synchronization facilities are not possible or do not provide
> the desired control. This method is applicable only when reclamation
> may have visible effects, which is possible for objects with
> finalizers (See Section 12.6 17 of The Java™ Language Specification)
> that are implemented in ways that rely on ordering control for
> These seem completely misleading to me.
> I would replace this with
> This method should be used when cleanup actions (finalize() calls, or
> Reference enqueuing, Cleaner invocation) could otherwise be triggered
> while a resource under control of the object is still in use. This
> method should normally be called when these cleanup facilities are
> used to perform actions other than simply issuing a warning.
> (Specific complaints about the original: In my experience, this is
> needed for the large majority of finalization/ReferenceQueue uses.
> What's the point of a finalizer without visible effects? The object is
> otherwise dead: Why bother? In practice, synchronization almost never
> provides the correct guarantees. Finalizers should indeed usually
> synchronize, but NOT on the object itself. It's not clear what
> "ordering control" here means. The order in which program actions are
> performed generally does matter.)
> The section starting with "It is sometimes possible to better
> encapsulate use of reachabilityFence..." just seems misleading. Delete
> it. I can't imagine a scenario in which that could work. Using files
> as a (bad for other reasons) example, assume the external resource is
> a file descriptor, and I'm about to read it. Keeping the file open
> until I retrieve the descriptor isn't good enough. It needs to be kept
> open for the duration of the read.
> I would replace the last paragraph with the following, or delete it
> entirely. I don't believe I've ever seen code to which it applies:
> ReachabilityFence is not needed when all uses of the embedded resource
> (including in the constructors or the finalize() method) are entirely
> enclosed in synchronized(this) blocks.
> (Note again that surrounding all accesses to the object itself in
> synchronized blocks does not suffice.)
Right, good suggestions.
Though I think that's out of scope for the current deprecation issue.
I created a new Issue  to track that and reference that/this email.
 8177915 Clarify Reference.reachabilityFence use
More information about the core-libs-dev