Как я должен поддерживать проекты JDK7, чтобы они могли автоматически понижаться для JDK6? - PullRequest
Новая
       24

Как я должен поддерживать проекты JDK7, чтобы они могли автоматически понижаться для JDK6?

3 голосов
/ 19 июня 2011

У меня мало собственных API с общим количеством классов около 2000.Некоторые из них используют новый Path API от JDK7.Однако большинство других классов не полагаются на любые новые API JDK или новые языковые функции.Поэтому большинство классов можно использовать в среде JDK6 (что я планирую сделать).Предположим, я аннотировал все классы только для JDK7 с помощью @Java7Only.

. Теперь мне нужен способ создания подмножества только для JDK6 всех моих проектов более или менее автоматически , без введения новой версии ветвления или линейки продуктов (было бы слишком сложно поддерживать).

Все проекты создаются с использованием Netbeans, таким образом, с использованием Ant.Многие проекты зависят от других.

Пожалуйста, помогите мне оценить, какие идеи в соответствии с моей проблемой являются наиболее подходящими.Какие проблемы могут возникнуть с каждой идеей?

Общий первый шаг для всех идей

  • Позволяет процессору аннотаций искать классы, аннотированные @Java7Only, и сохранять список в propertiesфайл.

Идея 1 (специфическая)

  • Напишите инструмент, который будет использовать файл properties для рекурсивного копирования всего проекта, кроме файлов только для JDK7.
  • Создайте скопированный проект, используя JDK6, вызвав ant, получив, таким образом, JDK6-совместимую флягу.

Идея 2 (специфическая)

  • Напишите вторую аннотациюПроцессор, который будет использовать файл properties для передачи всего, кроме файлов JDK7, в экземпляр JavaCompiler.
  • Либо создайте jar-файл с использованием Java API, либо используйте для этого Ant API.

(Это была бы идея только на Java, но, вероятно, слишком сложная)

Идея X (абстрактная)

  • Каким-то образом влияет на процесс сборки Ant (перезаписывая некоторые цели?) Идля каждого JDK6-совместимого класса: пусть Ant скомпилирует две версииНет (один раз с компилятором JDK6, другой раз с компилятором JDK7).
  • (классы только для JDK7 компилируются только один раз, конечно, с использованием компилятора JDK7)
  • Пакет каждыйкуча в отдельную банку.

Возможные общие проблемы с идеями

  • Некоторые проекты зависят от других, поэтому некоторые действия (например, упаковка) должны учитывать это.
  • Помните: компилятор JDK7 генерирует нисходящие несовместимые файлы классов, поэтому каждая возможная идея должна происходить на уровне источников (до или во время процесса сборки, а не после).

Ответы [ 2 ]

1 голос
/ 05 июля 2011

Мои мысли об идее 2:

По сути, это вызывает компилятор внутри компилятора. Процессоры аннотаций запускаются как часть компиляции. Можно ли это сделать безопасно? Есть ли статическое состояние в javac от Sun, которое могло бы вызвать проблемы? (Я не знаю ответа, но из памяти может быть некоторое статическое состояние, которое может вызвать проблемы в этом сценарии).

Идея 1 кажется мне проще и лучше.

Но, сделав шаг назад, можно ли выделить все специфические компоненты JDK 7 в отдельный модуль и скомпилировать его отдельно в другой JAR-файл?

  • Иметь «основной» проект, скомпилированный с использованием JDK 6 (который JDK 7 не будет иметь проблем при чтении, поскольку он обратно совместим)
  • Отдельные модули JDK 7 с источником в другом каталоге, который включает в себя «основной» JAR-файл на пути к классам компиляции, могут быть собраны отдельно, при необходимости с другим build.xml.
1 голос
/ 05 июля 2011

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

Проблема с использованием опций проверки -source 1.6 -target 1.6 заключается в том, что вы все равно можете использовать Java 7 API при компиляциииспользуя JDK 7.

Я использовал Animal Sniffer Maven Plugin для нескольких проектов сейчас, и он оказался весьма полезным.Этот плагин сканирует байт-код ваших классов на предмет использования JDK API.То есть, вы можете указать, что сборка будет неудачной, если вы попытаетесь использовать JDK 7 API, когда нацеливаетесь на JDK 6. Это не очень поможет для выделения классов по мере необходимости, но это может быть полезно в качестве заключительного этапа проверки в сочетании сsource 1.6 - опции компилятора target. 1.6.

Существует также плагин Ant анализатора животных, как упоминалось на главной странице Animal Sniffer .

...