2009-08-11 18 views
9

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 stanyJava 6 Source wstecznej kompatybilności i SQL

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):

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?

+0

Dodawanie metod nie przerywa zgodności w górę, tylko w dół (co jest dozwolone w przypadku wersji głównych, takich jak Java 6). –

+0

Ale typy 'java.sql' to interfejsy, a nie klasy. –

Odpowiedz

9

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.

+1

Czy powinno to być "nie * nie * powoduje prawdziwe problemy"? – nafg

1

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 ...

4

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.

+0

Prawidłowe. Właśnie dlatego ograniczyłem pytanie do kompatybilności źródeł! – notnoop

+1

To nie jest poprawne. Łamie wszystkie sterowniki zaimplementowane dla języka Java 5. Zobacz moje pytanie http://stackoverflow.com/questions/1238252/how-to-make-jdbc-driver-work-in-java-5-6 –

+1

@Zhang problem w zadane pytanie dotyczy zgodności binarnej w dół; tj. .. przy użyciu JDK Java 6 podczas kierowania na JDK Java 5. Java nigdy tego nie obiecała! – notnoop

1

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.

+0

Nie do końca prawda. Do pytania dołączono zasadę zgodności ze źródłami. Są łagodniejsze w rozwiązywaniu problemów ze źródłami niż w przypadku zgodności binarnej; ale zwykle dokumentują te zmiany. Zmiany 'java.sql' nie są udokumentowane w informacjach o wydaniu. – notnoop

Powiązane problemy