RFR 9: 8165641 : Deprecate Object.finalize

[Stuart Marks]

On 3/13/17 5:17 AM, Andrew Dinn wrote:
> On 13/03/17 12:15, Andrew Dinn wrote:
>> On 12/03/17 09:55, Andrew Haley wrote:
>>> Oh, absolutely, I know about that.  I was just wondering why now, and
>>> is this something you just came up with, and are we going to have the
>>> compatibility discussion?
>>
>> Perhaps now is the chosen moment (and a good choice at that, I say)
>> because deprecation in release N is necessary to allow removal or
>> modification of semantics in release N+k, k >= 1. So, rather N == 10
>> than N == 9 (n.b. in this case, I strongly suspect that inequality on k
>> will not actually encompass the equals case).
>
> Oops, obviously I meant:
>
>  So, rather N == 9 than N == 10

I wouldn't read too much into now being a "chosen moment" of any sort. With JEP 
277 [1] removal in a release >N requires deprecation with forRemoval=true in 
release N. This proposal isn't proposing forRemoval=true.

Instead, it's proposing the weaker form ("ordinary" deprecation), which is 
mostly a notification to programmers to avoid this mechanism and to look 
elsewhere for alternatives. This is pretty similar to what has been called 
"denigration" in the past [2].

As Alan mentioned, this has been discussed on and off for years. We've also been 
telling people informally for years not to use finalization. What happened 
recently was that we realized that upgrading this advice to be formal didn't 
need to wait until we had solved all of the problems with finalization.

s'marks


[1] http://openjdk.java.net/jeps/277

[2] https://bugs.openjdk.java.net/browse/JDK-6428760