I am the founder and CEO of Data Geekery GmbH, located in Zurich, Switzerland. With our company, we have been selling database products and services around Java and SQL since 2013. Ever since my Master's studies at EPFL in 2006, I have been fascinated by the interaction of Java and SQL. Most of this experience I have obtained in the Swiss E-Banking field through various variants (JDBC, Hibernate, mostly with Oracle). I am happy to share this knowledge at various conferences, JUGs, in-house presentations and on our blog. Lukas is a DZone MVB and is not an employee of DZone and has posted 241 posts at DZone. You can read more from them at their website. View Full User Profile

The Lame Side of Java’s Backwards-Compatibility

  • submit to reddit

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.Date and 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 int over 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:


Published at DZone with permission of Lukas Eder, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



John J. Franey replied on Mon, 2013/04/15 - 9:32am

To this post, I say "WTF?"

What does it mean to 'run out of 64bit space in 2139'?  (Google for '64bit 2139' does not answer this question.)

How is the return type of these jdbc functions dependent on this  'bit space' that we are running out of?

Because Java's method naming cannot differentiate between two methods with different return types but the same name, the only alternative to adding the above methods is to change the return type of the interface from int to long.  How would you phrase the explanation to developers that their code has to change even just to compile against the modified interface?

And how do 'defender' methods help?

According to the code in Statement, which you link, the Large methods have an ineffective default implementation,  and the non-Large methods are not marked Deprecated.   The non-Large methods are still part of the spec and there is no compelling reason for a developer to avoid using them.  So, your disgust is based on what?


Lukas Eder replied on Mon, 2013/04/15 - 9:51am in response to: John J. Franey

This was more of a rant, not to be taken too seriously. About your questions:

What does it mean to 'run out of 64bit space in 2139'?

As in: "in the year 2139" when we start updating 10^20 database rows at a time.

How would you phrase the explanation to developers that their code has to change even just to compile against the modified interface?

Nothing should be changed. I'm just saying that the added methods don't pull their own weight. Specifically not if (because of backwards-compatibility), the return type can no longer be adapted to a more suitable one.

And how do 'defender' methods help?

They help in the way that the new methods don't have to be implemented immediately by existing code (e.g. JDBC drivers, other tools), thanks to Java 8's new features.

So, your disgust is based on what?

By the mere fact that we now have things like:

  • doIt()
  • doItButDoItLarge()
It just looks like a very premature API addition for no compelling reason (to me). Few people are updating 2G rows at a time. And if they do, the return value is not their main concern. As I said. The added API complexity doesn't seem to pull its own weight.

John J. Franey replied on Mon, 2013/04/15 - 10:55am

Ok, I understand your rant's point, now; I got confused by the title and topic paragraph.  You were not ranting against bloat due to interfaces that are overdue for removal.  You are ranting against new additions that don't pull weight, at least until 2139. 

You are merely finding fault with the authors of the jdbc spec for adding methods you judge to be irrelevant.  I am still confused, though.  You find fault with the early jdbc for not having the foresight to have these methods return long, and you are finding fault with current spec team for having the same foresight that had been lacking.  You are right, I am taking your rant too seriously.

I wish dzone had a filter for 'rants not to be taken seriously'.

Lukas Eder replied on Mon, 2013/04/15 - 3:29pm in response to: John J. Franey

This post was reblogged in the "Opinions" category by the DZone curators. Feel free to give them some feedback.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.