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

[Stuart Marks]

On 5/11/16 2:37 PM, Martin Buchholz wrote:
> The problem is again that the library maintainer is not the same as
> the compiler invoker.
> A conscientious library maintainer does not stop at ensuring that
> their own builds are warning free; they want to ensure as much as they
> can that their users can also do $compiler -Xlint:all -Werror, even
> with future javac releases and other folks' toolchains.  Of course,
> this is an impossible task; compilers add warnings all the time.  But
> still one tries!
>
> JDK maintainers have the rare luxury of targeting only one release at a time.

OK, thanks for clarifying this. I hadn't quite followed your exchange with Peter 
Levart on this topic.

It looks to me like there are three general scenarios for handling different 
target versions:

1) Library sources built, targeted to JDK N (either by building on JDK N, or 
using -source/-target/-release); binaries run on JRE N .. JRE N+k.

2) Library sources maintained to be buildable on JDK N .. JDK N+k. This is what 
you do.

3) Library sources maintained to be buildable on JDK N .. JDK N+k plus other 
non-JDK toolchains. You might be doing this too. I'm aware of several non-JDK 
toolchains.

I mention (3) for completeness. I'm not sure what more there is to say about 
this, other than that it exists. If anyone has any thoughts, please contribute.

The main thing that's new to me is that you, and possibly others, are using (2). 
I'd be interested in how frequently (2) is used. My hunch is that most people 
use (1), but actually, that's something of a digression.

Anyway, let's get back to the main topic of this segment of the thread, which is 
the cost of deprecating something. If something you're using is deprecated in 
JDK N, then you can't migrate away from it until JDK N-1 and all earlier 
releases are no longer supported by your library. That could take years. Thus 
you have to use @SuppressWarnings to deal with the warnings.

So what's the driver of the cost? I'm thinking it's not the length of time that 
@SW has to be in your source base. The @SW for deprecated usages will have to 
stick around for the same length of time no matter what API is being deprecated. 
Is it instead the frequency of usage? So, for example, if there's one usage of 
something obscure that gets deprecated, it gets one @SW annotation. If that 
sticks around for ten years, no big deal.

On the other hand, if something that's used much more frequently were to be 
deprecated, then you'd have to sprinkle @SW around in perhaps hundreds of places 
in the source base, and they'd have to stay in there for years. I'm guessing 
that would have a much higher cost. Not only the work of putting in a bunch of 
@SW, but the decreased readability and maintainability caused by having @SW 
clutter up the code.

But again, I'm starting to guess a bit here. Is the cost imposed by deprecation 
based on the *principle* of not wanting to use APIs deprecated in a new JDK, 
even when compiling for an old JDK? Or is the cost imposed by the maintenance of 
having @SW all over the code, in order to control the warnings?

If the latter, then it would seem to me that more effective ways of controlling 
warnings would reduce your costs. I have some ideas about this but I don't want 
to start exploring them until it's clear that they would actually help.

s'marks