RFR 9: 8165641 : Deprecate Object.finalize

[Phil Race]

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.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.
>>
>>     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
>>
>>
>>
>