handling the deprecations introduced by early access builds 116 and 118 of jdk 9
Richard Hillegas
rhillegas at comcast.net
Mon May 30 18:48:15 UTC 2016
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
More information about the core-libs-dev
mailing list