On 5/10/16 7:59 PM, Martin Buchholz wrote:
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.
OK, sure, I get that there are libraries that will need to stay back on older
releases for a very long time. What I don't necessarily get is why they might
require @SuppressWarnings.
Let's take a somewhat concrete example, using an existing, recently-deprecated
API. The method
SecurityManager.checkMemberAccess(Class<?>, int)
had no deprecation annotation in Java 7, and it was deprecated in Java 8. (Its
deprecation was "upgraded" to forRemoval=true in Java 9, but let's just consider
7 and 8 for the moment.) Suppose I have some source code that uses this method,
and I compile it using JDK 7. Since I'm meticulous about this, I enable all lint
warnings and turn them into errors:
$ $JDK7/bin/javac -Xlint:all -Werror CheckMember.java
This works fine. If I recompile using JDK 8, then this happens:
$ $JDK8/bin/javac -Xlint:all -Werror CheckMember.java
CheckMember.java:6: warning: [deprecation] checkMemberAccess(Class<?>,int)
in SecurityManager has been deprecated
sm.checkMemberAccess(String.class, Member.PUBLIC);
^
error: warnings found and -Werror specified
1 error
1 warning
Disaster! Now I have to hack around with -Xlint options and @SuppressWarnings
annotations! Or do I? Since I want this thing to run on 7 and 8, I could just
continue compiling it using JDK 7, or if I want to compile using JDK 8, I can do
this:
$ $JDK8/bin/javac -Xlint:all -Werror -source 1.7 -target 1.7
-Xbootclasspath:$JDK7/jre/lib/rt.jar CheckMember.java
This completes with no warnings or errors. In JDK 9 (I'm using build 116) I can
do this:
$ $JDK9/bin/javac -Xlint:all -Werror -release 7 CheckMember.java
and again it completes with no warnings or errors. (I'm not sure why I have to
switch from 1.7 to 7.) Note also that I don't have to have a JDK 7 lying around
for this to work.
This works if you're willing to build once and use the same binary on different
JDK versions. Where you might run into trouble is if you want to use the same
source code and compile it using different JDK versions. Is this what you're
doing? If so, is there a reason you can't use the same binary on multiple
releases? If not, can you explain what you need to do that causes deprecation
warnings?
s'marks
