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
