Java 6 Source wstecznej kompatybilności i SQL

Question

Rozumiem, że aby zachować kompatybilność źródeł, Java nigdy nie wprowadza nowych metod dla publicznych interfejsów, ponieważ powoduje to zerwanie istniejących klientów implementujących interfejsy. Java Release notes stany

Generalnie zasada jest następująca, wyjątkiem wszelkich niezgodności wymienionych poniżej:

• komunikaty konserwacyjne (takie jak 1.4.1, 1.4.2 ) nie wprowadzić wszelkie nowe funkcje językowe lub interfejsy API. Będą one utrzymywać kompatybilność źródeł z nawzajem.

• uwalnia funkcjonalności i główne komunikaty (np 1.3.0, 1.4.0, 5.0) utrzymać w górę, ale nie w dół źródło kompatybilność.

Jednak pakiety java.sql i javax.sql nadal się rozwijać i wprowadzać wiele niezgodnych zmian. Na przykład, do następujących wniosków (niekompatybilne zmian wprowadzonych w Java 6):

• java.sql.Statement rozciąga java.sql.Wrapper wymagające nowego dwa nowe sposoby.
• java.sql.Statement wprowadza 3 nowe metody
• java.sql.PreparedStatement wprowadza 19 nowych metod!
• java.sql.ResultSet wprowadza 48 nowych metod!

Czy wiesz, jak i dlaczego te metody zostały dodane? Czy java.sql jest traktowane inaczej niż reszta platformy? Czy znasz dyskusję/JSR wokół tych dodatków?

Answer 1

dostałem następującą odpowiedź od dewelopera Sun

Ogólna polityka ewolucja dla API w JDK dla wydawnictw takich jak m.in. JDK 7 jest

1. Nie złamać kompatybilność binarną (zgodnie z definicją w JLSv3 rozdziale 13)
2. unikać wprowadzania źródło Niezgodności
3. Zarządzaj zmianę zachowania kompatybilności

(Aby uzyskać więcej, znacznie więcej niż można przeczytać na różnych rodzajach kompatybilności zobaczyć

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

Dodawanie metod interfejsów jest binarny kompatybilny ale źródło niezgodna , więc nie jest to często robione. Ogólnie rzecz biorąc, im szerszy jest interfejs, tym mniej prawdopodobne jest, że dodamy do niego metody. Obszar JDBC jest wyjątkiem od tej zasady i używa luźniejszych reguł aktualizacji, ale powoduje to prawdziwe problemy, gdy ludzie chcą dokonać aktualizacji do nowej wersji JDK.

Answer 2

Prawdopodobnie zakładają, że dostawcy sterowników baz danych, którzy wdrażają te metody, są na bieżąco z nowymi wersjami środowiska Java i że lepiej jest wprowadzić nowe użyteczne metody i tymczasowo zepsuć kompatybilność.

Oczywiście, mogliby Zaprojektowaliśmy go tak, że lepiej zerwania kompatybilności nie byłoby konieczne ...

Answer 3

Zauważ, że dodawanie nowych metod złamać tylko zgodność źródłowego, już skompilowane implementacje Statement lub ResultSet w sterownik JDBC będzie kontynuować działanie na nowszym JDK. Tylko wtedy, gdy spróbujesz wywołać nową metodę, otrzymasz numer NoSuchMethodError.

Answer 4

Firma Sun nigdy nie gwarantuje zgodności źródeł między wersjami, a jedynie zgodność binarną. Najczęstszym przykładem jest to, że kod źródłowy zawierający identyfikatory "assert" lub "enum" nie będzie kompilowany pod JDK 1.4 (dla assert) lub 1.5+ (dla enum), ale istniejące pliki .class nadal będą działały pod nowymi JVM.

Możesz spróbować użyć flagi -source, aby skompilować starsze pliki .java pod nowszymi maszynami JVM, ale nadal możesz napotkać problemy, jeśli polegasz na klasach jvm, które uległy zmianie.