Что можно сделать и не сделать с аннотациями Java? [закрытый]
5 ответов
Я почти уверен, что вы не можете использовать аннотации для стирки.
Но помимо этого, вот некоторые из реальных ограничений аннотаций в моем опыте:
- Они статичны. Это означает, что вы не можете заменить их какой-либо динамической конфигурацией времени выполнения. Поэтому, если у вас есть информация о базе данных, полученная из аннотации, это может быть очень ограничивающим фактором. Фреймворки, которые это делают, обычно требуют как механизмов конфигурации, так и аннотаций, а также некоторого XML или другого динамического механизма. Не совсем замечательно.
- Относящиеся к номеру 1, их трудно проверить. Представьте себе фреймворк, который должен обрабатывать некоторые аннотации. Создание всех вариантов для тестирования - это очень много шаблонов.
- Их трудно потреблять. И ошибки отражения, и просто общие трудности делают его подходящим для фреймворка, чтобы просить его пользователей написать аннотацию, но вы никогда не захотите, чтобы пользователь фреймворка должен был анализировать аннотации к параметру, чтобы что-то определять. .
Аннотации - это метаданные, информация об информации - в данном случае ваш код.
С помощью аннотаций вы можете предоставлять подсказки и подсказки потребителю аннотации, например компилятору или самому коду во время выполнения. Я использовал их осторожно в нескольких случаях, когда их присутствие заменяло необходимость в каком-то другом логическом сравнении, оценивающем истинность, а атрибуты предоставляли дополнительную информацию о том, что на самом деле нужно было сделать, потому что аннотация присутствовала.
Что касается того, что вы не можете делать с аннотациями ... Я не знаю, как на это ответить. Используйте их, если они решают реальную проблему или делают ваш код более элегантным, но не форсируйте это.
Простите меня за чрезмерное упрощение.
Мы используем аннотацию среды выполнения вместе с отражением, чтобы настроить отображение модели предметной области в базу данных. Также наша проверка формы основана на аннотациях в коде, используемом во время выполнения.
Кроме того, вы можете использовать процессор аннотаций, который поставляется с Java, для предварительной обработки ваших исходных файлов.
РЕДАКТИРОВАТЬ: А с lombok , как задано в Вопросе, был добавлен новый более мощный способ использования эта обработка аннотаций, чем, по мнению большинства присутствующих, была возможна. Позвольте мне описать это в нескольких словах: они перехватывают этап обработки аннотаций Java в
- Java-Compiler и
- Eclipse IDE, где генерируется дерево синтаксического анализа для вашего кода.
Таким образом, eclipse показывает вам больше кода, который вы действительно написали, и javac считает то же самое. Техника генерации использует старый стиль Java Annoation Processing, но вы можете думать о Lombok как о недостающем связующем, необходимом всем, чтобы сделать его действительно полезным.
Этот вопрос очень (слишком?) Широкий, поэтому я просто приведу один пример, который мне интересен. JPA 2.0 полагается на обработку аннотаций для создания статических классов метамодели для сущностей (используемых для типобезопасных запросов с Criteria API).
См. Также
Аннотации относятся к отражению. Сами по себе аннотации ничего не дают, их нужно использовать либо в коде, либо совместно с такими вещами, как динамический прокси или переписывание байт-кода, которые также относятся к области рефлексии.
Отражение известно как нечто чрезвычайно мощное, но в то же время оно может быть опасным.
Я думаю, что основной вопрос заключается в следующем: "Каковы законные способы использования аннотаций или, в более общем смысле, размышлений?".
Поскольку существует напряжение между рефлексией и безопасностью (разрывы системы типов, доступ к конечным полям и т.д.), есть два лагеря: те, кто принимает мета-программирование, и те, кто принимает безопасность. Что законно - это, в конечном счете, дело вкуса и мнения.
Смежные вопросы:
- Как и где аннотации используются в Java?
- Как ограничить setAccessible только "законным" использованием?
Судя по вашему комментарию, похоже, что вас в основном интересует JSR-269 и хукинг в процессе компиляции. Я вижу два варианта использования JSR-269: для пользовательских проверок ошибок/семантики (например, Override), для DSL/языковой инженерии. Будет ли он широко использоваться помимо хакинга и экспериментов, я не знаю. Вот, например, классные ссылки от коллеги:
Тем не менее, я бы сказал, что преобразование байт-кода/компиляторные хуки все еще относятся к мета-программированию. Например, вы можете генерировать getter/setter, как в Lombok, во время компиляции, или использовать динамический прокси, который делает это во время выполнения. Так что для меня эта двойственность означает, что мы все еще находимся в области рефлексии.