RFR(m): 8140281 deprecate Optional.get()

[Stuart Marks]

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?

s'marks