В каких случаях устаревший код Java не будет компилироваться в более новых версиях

Question

Java стремится к обратной совместимости.(Это в такой степени, что он урезал свои дженерики для этого).

Но есть ли ситуации, когда старый код не будет компилироваться в более новых версиях (более важно, Java 5 и предстоящая Java 7)

Answer 1

Кажется, их на самом деле довольно много - ну, не все из них приводят к ошибке компиляции, но это официальное слово от sun: http://java.sun.com/j2se/JM_White_Paper_R6A.pdf

Обычно я использую эти проверки:

1. До версии 1.4 URLConnection.getInputStream вызывал исключение FileNotFoundException, если тип файла был известен, а код ответа был больше или равен 400. В противном случае исключение не было бы выдано

2. HttpURLConnection.getErrorStream может использоваться для чтения страницы ошибки, возвращаемой с сервера. Перед 1.4, getErrorStream () всегда возвращал ноль.

3. В интерфейсы DOM были добавлены новые методы, поэтому некоторые существующие приложения не смогут скомпилироваться с новыми интерфейсами.

4. ErrorHandler, EntityResolver, ContentHandler и DTDHandler теперь могут быть установлены равными нулю приложениями. В этом случае SAX 2.0 требовал, чтобы процессор XML выдавал исключение java.lang.NullPointerException. (Парсер JAXP, реализованный в 5.0, как и большинство реализаций, реагирует на ноль, используя настройки по умолчанию.)

5. Метод resolEntity в DefaultHandler и подклассе EntityResolver генерирует исключения IOException и SAXException. Раньше выкидывал только SAXException.

6. В SAX 2.0.1 приложение может установить для ErrorHandler, EntityResolver, ContentHandler или DTDHandler значение null. Это ослабление предыдущего ограничения в SAX 2.0, которое генерировало исключение NullPointerException (NPE) в таких обстоятельствах.

7. Начиная с 5.0, XSLTC является преобразователем по умолчанию, XSLTC не поддерживает все расширения, которые поддерживает Xalan. Эти расширения выходят за рамки спецификаций JAXP и XSLT.

8. В 5.0 классы org.apache переместились в 5.0 в com.sun.org.apache.package.internal, чтобы они не конфликтовали с более свежими версиями классов, загруженными разработчиками.

9. Метод BigDecimal изменил свое поведение между 1.4 и 5.0, что привело к сбою драйверов JDBC.

10. Начиная с 5.0, сравнение java.sql.Timestamp с java.util.Date путем вызова compareTo для Timestamp приводит к ClassCastException.

11. Класс java.net.Proxy был добавлен в 5.0, что сделало два класса с именем Proxy: (Java.lang.reflect.Proxy, java.net.Proxy)

12. Следующие слова были добавлены в язык Java между 1.3 и 5.0, поэтому они больше не доступны для использования в качестве идентификаторов полей или методов: [assert (добавлено в 1.4), enum]

Answer 2

Да, например, при использовании enum в старых jdks:

Enumeration enum = ...

будет компилироваться с jdks до 1.5.

Answer 3

Новые версии могут не «сломать» что-либо, но при этом ваш код не будет компилироваться.

Например, в JDK5 был добавлен метод Timer.getId(), который возвращает long.
На самом деле у нас был класс с подклассами Thread и собственный метод getId, который возвращал строку. Это, конечно, вызвало проблемы компиляции, потому что мы внезапно пытались переопределить метод и изменить тип его возвращаемого значения.

Answer 4

Самые неприятные проблемы, с которыми я недавно столкнулся ¹ с переносом кода, были с Eclipse на OSX. Проблема была с миграцией Java5 → 6 и была связана с тем, что в OSX сборка Java5 по умолчанию была 32-битной, а единственная сборка Java6 была 64-битной. Это вызвало много проблем, потому что SWT (на котором построен Eclipse) использует собственный код.

Другая вещь, о которой я знаю, это путаница, с которой вы можете столкнуться с различными библиотеками, которые поддерживают веб-сервисы, но обычно я обнаружил исправление, которое заключается в обновлении до Java6 и использовании системных библиотек, где это возможно. Это область, где Java6 был значительно лучше, чем 5.

---

¹ Чтобы быть справедливым, это было некоторое время назад, и более новые сборки Eclipse поставляются с необходимыми встроенными обходными путями.

Answer 5

Однажды у меня была связанная проблема с Class # getRessource () - некоторый код, который хорошо скомпилирован под 1.4.2 и 1.5+, но не работал на JVM> 1.4.2.

И я помню некоторыепроблемы со сторонними библиотеками (некоторые версии bea weblogic 8.1.4, если я правильно помню), которые отказывались сотрудничать в среде Java 1.5, потому что какой-то интерфейс был перемещен в другой пакет (это давно, поправьте меня, если детали неточный.)

Answer 6

В какой-то момент они забрали getenv, но затем в следующей версии они вернули его обратно.

Однажды у меня возникла проблема, когда имя нового библиотечного класса конфликтовало с именем класса, который мы создали. Мы использовали «import java.whwhatitwas. *», Поэтому мы перетянули новый класс, даже не подозревая об этом. Я забыл, каково было название класса, но это может случиться с вами с любым новым классом, особенно с классическим именем, таким как «Список» или «Карта».

Это единственные проблемы с новыми версиями, о которых я вспоминаю.

Answer 7

Методы и классы могут быть помечены как устаревшие, что приведет к ошибке времени компиляции. Но вы можете сказать компилятору игнорировать это. Кроме перечисления, вы можете скомпилировать