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

[Peter Levart]

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