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 methodsjava.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?
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
(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.