On 05/11/2016 02:44 AM, Stuart Marks wrote:
On 4/28/16 7:23 PM, Martin Buchholz wrote:
No opinion on Optional.get() itself, but here's an opinion on the high
cost of deprecation.
If you deprecate the API today, and I have a library that is already
using the API, then I should add a @SuppressWarning("deprecation")
today and keep it there until the number of people using pre-jdk9 is
insignificant, when I can finally rename it. How long is that? These
days, I estimate at least 10 years. But even 20 years is quite
possible.
Hi Martin,
Finally getting back to this.
Thanks for this observation on the cost of deprecation. I think there
are several things going on here.
One is how long such annotations need to live in the source base. I
see the concern but I'm not sure where you're getting your lifetime
numbers. Certainly there's a support lifetime for old JDK releases.
I'm hearing about various systems migrating away from Java 7 now, and
that's five years old. There are still various things that need to
support Java 6 (ten years old), but I think this is exacerbated by the
abnormally long gap between 6 and 7.
But, continuing the scenario, suppose something is deprecated in JDK
9, and you add @SuppressWarnings to shut off the new warnings it
generates. You can't migrate to the replacement API introduced in JDK
9, since you still have to support JDK 6, 7, and 8, so you have to
leave @SW in until you drop support for 8, which might not be for many
years. Is that the source of your concern? I'm kind of guessing here.
An additional problem with @SuppressWarnings("deprecation"), and its
companion command-line option -Xlint:-deprecation, is that it's too
broad a brush. They shut of *all* deprecation warnings, at least, for
the scope of code to which they're applied. If @SW is added to
suppress deprecation warnings on X, and later on Y is deprecated,
deprecation warnings on uses of Y will also get suppressed. That's
likely a problem.
It seems to me that when we're talking about costs of deprecation, the
main issue is how to manage warnings, in code bases that support
multiple releases, and when different things are deprecated in
different releases. Is it really about warnings? Or is there some
other cost that we should be thinking about as well?
Couldn't this new @Deprecated.since annotation attribute play a role
here? For example, if you are building with JDK 9 javac, but specify
-release 8 option, then you don't get deprecation warning for methods
annotated with @Deprecated(since = "9").
Regards, Peter
s'marks
