Обратная совместимость с Java 6 Source и SQL

Question

Насколько я понимаю, для обеспечения совместимости с исходным кодом Java никогда не вводит новые методы в общедоступные интерфейсы, поскольку это нарушает работу существующих клиентов, реализующих интерфейсы. Замечания по выпуску Java состояния

В общем, политика выглядит следующим образом: за исключением любых несовместимостей перечислены ниже:

• Вспомогательные выпуски (такие как 1.4.1, 1.4.2) не вводить какие-либо новые языковые функции или API. Они будут поддерживать исходную совместимость с друг друга.

• Функциональные выпуски и основные релизы (такие как 1.3.0, 1.4.0, 5.0) поддерживать вверх, но не вниз источник-совместимость.

Тем не менее, пакеты java.sql и javax.sql продолжают развиваться и вносить множество несовместимых изменений. Например, я заметил следующие несовместимые изменения (введенные в Java 6):

• java.sql.Statement расширяет java.sql.Wrapper, требуя новых двух новых методов.
• java.sql.Statement вводит 3 новых метода
• java.sql.PreparedStatement вводит 19 новых методов!
• java.sql.ResultSet вводит 48 новых методов!

Знаете ли вы, как и почему эти методы были добавлены? java.sql трактуется иначе, чем на остальной платформе? Знаете ли вы об обсуждении / JSR вокруг этих дополнений?

Answer 1

Я получил следующий ответ от Sun Developer

Общая политика развития для API в JDK для выпусков функций, таких как JDK 7, равна

1. Не нарушать бинарную совместимость (как определено в главе 13 JLSv3)
2. Избегайте введения несовместимости источников
3. Управление изменениями поведенческой совместимости

(Более подробную информацию о различных видах совместимости, которую вы хотели бы прочитать, см.

«Виды совместимости: исходные, двоичные и поведенческие» а также "Совместимо развивающийся BigDecimal"

Добавление методов к интерфейсам является двоичным совместимым , но source несовместимым, поэтому обычно это не делается. Как правило, чем шире реализован интерфейс, тем меньше вероятность того, что мы добавим к нему методы. Область JDBC является исключением из этой политики и использует более свободные правила обновления, но это вызывает реальные проблемы, когда люди хотят перейти на новую версию JDK.

Answer 2

Обратите внимание, что добавление новых методов только нарушает совместимость исходного кода, уже скомпилированные реализации Statement или ResultSet в драйвере JDBC будут продолжать работать на более новом JDK. Только при попытке вызвать новый метод вы получите NoSuchMethodError.

Answer 3

Sun никогда не гарантирует исходную совместимость между выпусками, только двоичную совместимость. Наиболее распространенным примером является то, что исходный код, содержащий идентификаторы «assert» или «enum», не будет компилироваться в JDK 1.4 (для assert) или 1.5+ (для enum), но существующие файлы .class будут по-прежнему работать в этих более новых JVM.

Вы можете попробовать использовать флаг -source для компиляции более старых файлов .java в более новых JVM, но у вас могут возникнуть проблемы, если вы полагаетесь на измененные классы jvm.

Answer 4

Они, вероятно, предполагают, что производители драйверов баз данных, которые реализуют эти методы, постоянно обновляются с новыми средами выполнения Java, и что лучше вводить новые полезные методы и временно нарушать совместимость.

Конечно, они могли бы спроектировать его лучше, чтобы не было необходимости нарушать совместимость ...