Подтвердить что ты не робот

Есть ли фрагмент программы Java, который может компилироваться с помощью компилятора Java 5 на JRE 6, но не компилятором Java 6?

Я хочу иметь исходный файл, который может компилироваться с javac/ecj, установленным на Java 5, но не с Java 6 (даже если базовая среда Java - это Java 6).

Это должно быть уверенным, что уровень компилятора правильно установлен в Eclipse 3.5, работающем с установленным Java 6, но где результат должен выполняться на установке Java 5.

Для java 1.4 я мог бы использовать "enum" в качестве имени переменной (которая не работает под Java 5 и более поздней), но я не могу найти аналогичный подход для Java 5 по сравнению с 6 (и позже).

Предложения?

4b9b3361

Ответ 1

В языке Java, который был удален между JDK5 и 6., ничего не осталось. Единственное, что было добавлено, как уже было сказано, это аннотация @Override, допустимая для методов интерфейса - без ключевых слов. Поэтому, я боюсь, что вы остаетесь с различиями в библиотеке как единственная причина нарушения.

Они существуют даже в базовом API; в необычном подходе к разгадке с обратной совместимостью они изменили подпись некоторых методов на интерфейсе ExecutorService. Это объясняется тем, что общие подписи методов были чрезмерно ограничительными. Это была чистая замена библиотеки (хотя она была частью java.util, красивой основной библиотеки); не имеет ничего общего с какой-либо модификацией на уровне языка.

Например, из JDK5:

<T> T invokeAny(Collection<Callable<T>> tasks)

в JDK6:

<T> T invokeAny(Collection<? extends Callable<T>> tasks)

Это означает, что любая программа, содержащая код, реализующий этот интерфейс в JDK5, не была бы скомпилирована против JDK6. Фрагмент легко создать; просто позвольте вашей среде IDE создать пустую реализацию интерфейса JDK5, а затем построить против JDK6.

Примечание:, что шаблон был добавлен, потому что предыдущая версия не приняла такой параметр, как List<MyCallable<String>> (т.е. коллекция была набрана каким-то подклассом вызываемого), а более поздняя версия.

Ответ 2

Так как JVMDI был удален, а JVMPI отключен в Java SE 6 (согласно заметка о выпуске J2SE 6.0), вы можете добавить код с помощью этого API: он не будет компилироваться с J2SE 6.0, всего 5.0. (как показано этот поток)

Ответ 3

Не ответ на ваш вопрос, а альтернатива вашему подходу: нельзя ли использовать второй строитель на основе ant или maven, который вы используете по требованию для создания окончательного приложения или библиотеки? Эта сборка будет использовать реальный внешний SDK Java 5 и, таким образом, гарантировать, что приложение/библиотека будет работать в среде Java5.