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
