RFR 9: 8165641 : Deprecate Object.finalize
philip.race at oracle.com
Fri Mar 31 17:48:10 UTC 2017
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 ..
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?
> 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.Riggs at oracle.com
>> <mailto:Roger.Riggs at 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.
>> Thanks, Roger
More information about the core-libs-dev