RFR 9: 8165641 : Deprecate Object.finalize

[Hans Boehm]

This is great as far as it goes. But (due to its age?) it seems to omit
what I would consider the top two issues:

1. Objects can be finalized while a method on the object is still running.
Yes, reachabilityFence addresses this, and is an important improvement. But
it reachabilityFence remains extremely difficult to use, and essentially no
current code does. This problem is shared with java.lang.ref and Cleaner.
In my experience, the large majority of existing code using finalize() is
broken by this, though failures in the field tend to be fairly rare. Any
code deallocating native memory needs to be aware of this issue. Code that
just reports "you forgot to close this" is probably OK. Where I sit, the
former is much more common than the latter.

2. Objects are finalized in arbitrary order, which means that finalizers
can see objects that have already been finalized. This is fixed by the
later APIs. In my mind, it's the main argument for deprecating
Object.finalize(). (I would personally argue for deprecate then fix, rather
than deprecate then remove. But that's controversial, and we probably don't
want to go there.)

Unlike the other complaints, both of these, when used to manage native
memory through JNI, can result in corruption of the native heap, and are
thus particularly difficult to recover from.

They are discussed in e.g.
https://www.hboehm.info/misc_slides/java_finalizers.pdf

Hans

On Mon, Mar 13, 2017 at 6:32 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi,
>
> A reasonably complete treatment of finalizers and suggestions for correct
> use are in Josh Bloch' Effective Java.  It may be a bit dated but is a
> good start for the casual reader.
>
> Josh provided an excerpt:
> http://www.informit.com/articles/article.aspx?p=1216151&seqNum=7
>
> There is a lot more to do to design better APIs and mechanisms for the most
> difficult cases.  Project Panama is working on some of them and more than
> a few
> ideas are being developed (as noted in earlier emails).
>
> Roger
>
>
>
> On 3/13/2017 9:07 AM, Doug Lea wrote:
>
>> On 03/12/2017 07:55 PM, Hans Boehm wrote:
>>
>> But I think we agree that it doesn't matter for this discussion; neither
>>> of
>>> these problems are addressed by deprecating finalizers. PhantomReferences
>>> have exactly the same issues. ...
>>>
>>
>> The motivation seems more along the lines of "denigration" vs
>> deprecation. But even if so, I agree with Hans's implicit claim that
>> it might be better to thoroughly document all the issues encountered
>> when using finalization and/or PhantomReferences and/or cleaners, etc.
>> This coverage will necessarily convey the high expertise required to
>> implement and use them effectively, and to not use them otherwise.
>> Currently no single authoritative account exists, so a lot of
>> errors are due to confusion or ignorance. Doing better would seem
>> to be the highest priority. But maybe adding deprecation warnings
>> on top of this will have some beneficial effect. So, like Hans,
>> I'm not completely opposed to this, but not excited either.
>>
>> -Doug
>>
>>
>>
>>
>