Java 6 Source backward-compatibility and SQL

Question

My understanding is that in order to maintain source-compatibility, Java never introduces new methods to public interfaces, as that breaks existing clients implementing the interfaces. Java Release notes states

In general, the policy is as follows, except for any incompatibilities listed further below:

• Maintenance releases (such as 1.4.1, 1.4.2) do not introduce any new language features or APIs. They will maintain source-compatibility with each other.

• Functionality releases and major releases (such as 1.3.0, 1.4.0, 5.0) maintain upwards but not downwards source-compatibility.

Yet, the packages java.sql and javax.sql continue to evolve and introduce many incompatible changes. For example, I noticed the following incompatible changes (introduced in Java 6):

• java.sql.Statement extends java.sql.Wrapper, requiring new two new methods.
• java.sql.Statement introduces 3 new methods
• java.sql.PreparedStatement introduces 19 new methods!
• java.sql.ResultSet introduces 48 new methods!

Do you know how and why these methods got added? Is java.sql being treated differently from the rest of the platform? Do you know of the discussion/JSR around these additions?

Answer 1

They probably assume that database driver vendors that implement those methods are keeping up-to-date with new Java runtimes, and that it's better to introduce useful new methods and temporarily break compatibility.

Of course, they could've designed it better so that breaking compatibility wouldn't be necessary…

Answer 2

Note that adding new methods only break source compatibility, already compiled implementations of Statement or ResultSet in a JDBC driver will continue to run on a newer JDK. Only when you try to call a new method you will get a NoSuchMethodError.

Answer 3

Sun never guarantees source compatibility between releases, only binary compatibility. The most common example is that source code that contains 'assert' or 'enum' identifiers will not compile under JDK 1.4 (for assert) or 1.5+ (for enum), but existing .class files will still run under those newer JVMs.

You can try using the -source flag to compile older .java files under newer JVMs but you may still run into problems if you're relying on jvm classes that have changed.

Answer 4

I got the following reply from a Sun Developer

The general evolution policy for APIs in the JDK for feature releases like JDK 7 is

1. Don't break binary compatibility (as defined in JLSv3 chapter 13)
2. Avoid introducing source incompatibilities
3. Manage behavioral compatibility change

(For more, much more than you'd like to read on different kinds of compatibility see

"Kinds of Compatibility: Source, Binary, and Behavioral" and "Compatibly Evolving BigDecimal")

Adding methods to interfaces is binary compatible but source incompatible, so it is not commonly done. Generally, the more widely implemented an interface is, the less likely we are to add methods to it. The JDBC area is an exception to this policy and uses looser upgrade rules, but that does cause real issues when people want to upgrade to a new JDK release.