handling the deprecations introduced by early access builds 116 and 118 of jdk 9

[Richard Hillegas]

Dalibor Topic recommended that I post this feedback on core-libs-dev. 
This is my feedback after ameliorating the deprecation warnings which 
surfaced when I compiled and tested Apache Derby with early access 
builds 116 and 118 of JDK 9. Derby is a pure Java relational database 
whose original code goes back almost 20 years. Other large, old code 
bases (like Weblogic) may have similar experiences. More detail on my 
experience can be found on the JIRA issue which tracks the Derby 
community's attempt to keep our code evergreen against JDK 9: 
https://issues.apache.org/jira/browse/DERBY-6856

o Deprecating autoboxing constructors - Deprecating the autoboxing 
constructors for primitive wrapper objects caused a large rototill of 
Derby code. That rototill was comparable in size to the changes made 
necessary by Java 5's introduction of generics. Hopefully, IDEs can 
automate much of this chore.

o Deprecating Class.newInstance() - The deprecation of 
Class.newInstance() forced a similarly large rototill. The code became 
more verbose. Additional exceptions had to be caught and propagated up 
the call stack. For reasons which I don't understand, I had better luck 
using Class.getConstructor().newInstance() than 
Class.getDeclaredConstructor().newInstance(). But the former replacement 
code requires you to make constructors public. For some code bases, that 
may introduce security problems which are worse than the security 
problem being addressed by this deprecation. I hope that IDEs and the 
release notes for JDK 9 will provide some guidance for how to handle 
these issues.

o Deprecating java.util.Observable and java.util.Observer - Two 
ameliorations are recommended at 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040436.html. 
The first suggestion (use the awt event model) runs very much counter to 
the whole intent of Jigsaw. That is because pulling in awt can bloat up 
an application with large, otherwise unneeded libraries. Using awt was 
out of the question for Derby, given that the community had already 
invested a great deal of effort in paring back Derby's dependencies in 
order to let the code run on JDK 8 compact profile 2. That left us with 
the other option: write your own replacement classes. If a lot of people 
end up having to write the same replacement code, then that argues for 
leaving this small but useful functionality in the JDK. I think that the 
people who advocated for this deprecation did not have good visibility 
into how widely these classes are being used in the wild. I recommend 
that this deprecation be re-evaluated.

Thanks,
-Rick