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

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

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

Ответы

Ответ 1

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

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

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

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

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

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

  • Метод resolveEntity в подклассе DefaultHandler и EntityResolver вызывает исключение IOException и исключение SAXException. Ранее он выдавал только исключение SAXException.

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

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

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

  • Метод BigDecimal изменил свое поведение между 1.4 и 5.0, в результате чего драйверы JDBC были сбойными.

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

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

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

Ответ 2

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

Enumeration enum = ...

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

У меня когда-то была проблема, когда новое имя класса библиотеки противоречило имени класса, который мы создали. Мы использовали "import java.whateveritwas. *", Поэтому мы перетащили новый класс, даже не зная об этом. Я забыл, что такое имя класса, но это может случиться с вами с любым новым классом, особенно с довольно общим именем типа "Список" или "Карта".

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

Ответ 6

У меня когда-то была проблема с Class # getRessource() - некоторый код, который скомпилирован под 1.4.2 и 1.5+, но не работал на JVM > 1.4.2.

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

Ответ 7

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

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

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