The Lame Side of Java’s Backwards-Compatibility
Java is a very backwards-compatible language. Very as in very very very. It is so backwards compatible, we still have tons of deprecated code that was deprecated in the JDK 1.1. For example, most of the
java.util.Calendar API. Some may argue that it would’ve been easier to deprecate the classes altogether…
But things don’t get better as we’re approaching Java 8. Please, observe with me with a mixture of intrigue and disgust what is going to be added to the JDBC 4.2 specs:
“large”. As in “We should’ve made that a
long instead of an
int from the very beginning”. Luckily, Java 8 also introduces defender methods, such that the additions were done backwards-compatibly.
I wonder how many other places in the JDK should now have duplicate methods using the “large” term, because in the beginning, people chose
long, when most processors were still 32bit, and it really did make a difference.
Also, I wonder what’ll happen when we run out of 64bit space in the year 2139, as mankind will reach the outer skirts of milky way. In order to be able to write the occasional planet-migration script, we’ll have to add things like
executeHugeUpdate() to the JDBC specs in Java 11 – if we’re optimistic that Java 11 will be shipped by then
For more info, you can see the up-to-date OpenJDK source code here:
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)