Consider a library like guava classic. It currently supports jdk 6+,
and there's a good chance that library will do that until its end of
life, which is likely to be around the time when EVERYBODY is using
jdk 8+, which is still many years away. Even there, it would be nice
to compile with javac 9 without any warnings. Proliferation of
deprecation warnings in new JDK releases leave conscientious library
maintainers with no choice but to spray @SuppressWarnings everywhere.
They may even end up doing so preemptively. The deprecation warnings
are pure pain; no benefit; the replacement API may never be an option
for such a library.
The older Java gets, the more players in the ecosystem, and the slower
the adoption curve.
Maybe if we were serious about the javac -release flag, we would have
deprecation warnings only when the replacement API is actually
available in the targeted release? That might be progress!
On Tue, May 10, 2016 at 5:44 PM, Stuart Marks <stuart.ma...@oracle.com> 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?
>
> s'marks
