Какой смысл аннотаций пакета?

Ответ 1

• bnd tool (и maven-bundle-plugin) использует аннотации пакетов. Ввод @Version и аннотация @Export в package-info.java позволяет генерировать метаданные OSGi.
• javadoc использует аннотации пакетов.
• JAXB использует аннотации на уровне пакетов, например, чтобы указать сопоставление типа Java с типом схемы XML в пакете. Аннотации пакетов также используются в привязке XML-кода JBoss.
• Плагин Struts 2 Convention использует аннотацию для указания перехватчика по умолчанию для всех действий в пакете.
• Есть несколько уровней Hibernate Annotations. Пример использования этих аннотаций можно найти здесь.

Ответ 2

Я полагаю, что @Deprecated имеет смысл. И, возможно, что-то вроде @Generated, если весь пакет был сгенерирован каким-то инструментом из источника, отличного от Java. Или @Internal, если этот пакет не является частью общедоступного API.

Возможно, инструменты OSGi (где вам нужно объявить версии ваших пакетов и пакеты, на которых вы зависите) также могли бы использовать это.

Кто-нибудь видел людей в дикой природе?

Ответ 3

Две причины, о которых я могу думать:

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

Ответ 4

JAXB, например, позволяет большинство аннотаций, которые обычно используются для типа, который одинаково хорошо применяется к пакету. Смысл в этом случае - указать значение по умолчанию для всех классов в этом пакете.

Например, если вы хотите, чтобы все свойства всех классов в пакете, которые были показаны с помощью getter/seters, были отображены в XML, вы могли бы указать @XmlAccessorType(XMLAccessType.PROPERTY) для каждого класса или просто указать его на пакет.

Ответ 5

Это не настоящая цель, но я использую их как обходной путь, чтобы избежать перекомпиляции файлов package-info.java.

Проблема заключается в том, что javac (и Ant task <javac>) не создает файл класса для package-info.java, если есть только документация (причина их существования) и оператор package bla;, и что задача Ant перекомпилирует каждый файл, для которого нет (или более старого) соответствующего файла .class.

Добавление фиктивной аннотации там (например, SuppressWarnings) привело к созданию a package-info.class и, следовательно, файл не перекомпилировался до тех пор, пока не будет изменен снова.

(Ant 1.8.0 решил это, создав пустой пакет-info.class, даже если не было аннотации, но я использую более старый ant здесь.)

Ответ 6

Тестирование метаданных - это метаданные вокруг тестовых пакетов (модульные тесты или другие). Вы можете приписать различные фрагменты тестовых метаданных, которые подходят на уровне пакета, например: функции, владельцы, версии, ошибки/проблемы и т.д. Они могут быть уточнены на уровне класса или метода, но с определениями уровня пакета или значениями по умолчанию может быть удобно для краткости. Я использовал вариант этого подхода (до использования аннотаций).

Аналогичный аргумент можно было бы сделать для обобщенных метаданных кода вокруг одного и того же вида вещей: функций, прав собственности, дефектов, исторической информации и т.д.