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

[Stuart Marks]

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