Недостатки обработки аннотации в Java?
Дополнительно к бастионному хозяину. Вы можете подключить Virtual Private Gateway к вашему VPC, установить VPN-соединение между вашей частной подсетью (где находится ваша RDS) и вашим локальным шлюзом / маршрутизатором и подключаться через SSH с использованием частных IP-адресов, без необходимости хоста бастиона. [ 110]
3 ответа
Я создал набор аннотаций JavaBean ( http://code.google.com/p/javadude/wiki/Annotations )
[Примечание: я работаю на новой версии прямо сейчас, поэтому код транка не соответствует загрузкам с сайта обновления]
Тестирование
Тестирование их может быть довольно трудным ...
Обычно я подхожу к нему, создавая проект в затмении с тестовым кодом и собирая его, затем делаю копию и отключаю обработку аннотаций.
Затем я могу использовать Eclipse для сравнения «активного» тестового проекта с «ожидаемой» копией проекта.
У меня пока не так много тестов (очень сложно создавать так много комбинаций атрибутов), но это помогает.
Система сборки
Использование аннотаций в системе сборки на самом деле очень просто. Посмотрите на http://code.google.com/p/javadude/wiki/Annotations пример того, как он используется в сценарии ant, и использование его в eclipse - это всего лишь вопрос создания плагин, определяющий расширение процессора аннотаций и включающий обработку аннотаций в проектах, которые хотят его использовать.
Я использовал обработку аннотаций в среде непрерывной сборки, создавая аннотации & amp; процессор, а затем использовать его в остальной части сборки. Это действительно довольно безболезненно.
Время обработки
Я не считаю, что это является проблемой - будьте осторожны с тем, что вы делаете в процессорах. Я генерирую много кода в моем, и он работает нормально. У муравья немного медленнее.
Обратите внимание, что процессоры Java6 могут работать немного быстрее, потому что они являются частью обычного процесса компиляции. Однако у меня возникли проблемы с тем, чтобы заставить их работать должным образом с возможностью генерации кода (я думаю, что большая часть проблемы заключается в поддержке eclipse и запуске многофазных компиляций). Сейчас я придерживаюсь Java 5.
Обработка ошибок
Это одна из наиболее продуманных вещей в API аннотаций. В API есть объект "messenger", который обрабатывает все ошибки. Каждая IDE предоставляет реализацию, которая преобразует это в соответствующие сообщения об ошибках в нужном месте кода.
Единственное, что я делал для конкретного затмения, было приведение объекта среды обработки, чтобы я мог проверить, был ли он запущен как сборка или для согласования редактора. Если редактирую, я выхожу. В конце концов я изменю это, чтобы просто выполнять проверку ошибок во время редактирования, чтобы она могла сообщать об ошибках по мере ввода Однако будьте осторожны - вам нужно, чтобы он был действительно быстрым, чтобы его можно было использовать во время сверки, или редактирование замедляется.
Gotcha для генерации кода
[добавлено чуть больше для комментариев]
Спецификации процессора аннотаций указывают, что вам не разрешено изменять класс, содержащий аннотацию , Я подозреваю, что это должно упростить обработку (дальнейшие раунды не должны включать аннотированные классы, предотвращая также бесконечные циклы обновления)
Вы можете генерировать другие классы, однако, и они рекомендуют этот подход.
Я генерирую суперкласс для всех методов get / set и всего, что мне нужно сгенерировать. У меня также есть процессор, чтобы убедиться, что аннотированный класс расширяет сгенерированный класс. Например:
@Bean(...)
public class Foo extends FooGen
Я генерирую класс в том же пакете с именем аннотированного класса плюс «Gen» и проверяю, что аннотированный класс объявлен для его расширения.
Я видел, как кто-то использовал API дерева компилятора для изменения аннотированного класса - это против спецификации, и я подозреваю, что в какой-то момент они закроют эту дыру, чтобы она не работала.
Я бы порекомендовал создать суперкласс.
В целом
Я действительно счастлив, используя процессоры аннотаций. Очень хорошо разработан, особенно с точки зрения независимости сборки IDE / командной строки.
На данный момент, я бы порекомендовал придерживаться процессоров аннотаций Java5, если вы делаете генерацию кода - вам нужно запустить отдельный инструмент под названием apt для их обработки, а затем выполнить компиляцию.
Обратите внимание, что API для процессоров аннотаций Java 5 и Java 6 отличается! API обработки Java 6 лучше IMHO, но мне просто не повезло с процессорами java 6, делающими то, что мне нужно.
Когда выйдет Java 7, я еще раз попробую новый подход к обработке.
Не стесняйтесь, напишите мне, если у вас есть вопросы. (scott@javadude.com)
Надеюсь, это поможет!
Одна конкретная вещь, которая будет полезна при ответе на вопрос, будет в отличие от чего? Не выполняете проект или не используете аннотации? И если не использовать аннотации, каковы альтернативы?
Лично я нахожу чрезмерные аннотации нечитаемыми, а во многих случаях слишком негибкими. Взгляните на это для одного метода в веб-сервисе для реализации WSDL, требуемого поставщиком:
@WebMethod(action=QBWSBean.NS+"receiveResponseXML")
@WebResult(name="receiveResponseXML"+result,targetNamespace = QBWSBean.NS)
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public int receiveResponseXML(
@WebParam(name = "ticket",targetNamespace = QBWSBean.NS) String ticket,
@WebParam(name = "response",targetNamespace = QBWSBean.NS) String response,
@WebParam(name = "hresult",targetNamespace = QBWSBean.NS) String hresult,
@WebParam(name = "message",targetNamespace = QBWSBean.NS) String message) {
Я считаю, что этот код крайне нечитаемый. Однако альтернатива конфигурации XML не обязательно лучше.
Я думаю, что если процессор аннотаций, то определенно используйте версию API для Java 6. Это тот, который будет поддерживаться в будущем. API Java 5 все еще находился в неофициальном пространстве имен com.sun.xyz.
Я думаю, что в ближайшем будущем мы увидим гораздо больше применений API процессора аннотаций. Например, Hibernate разрабатывает процессор для новой функциональности статической метамодели, связанной с запросами JPA 2. Они также разрабатывают процессор для проверки аннотаций Bean Validation. Так что обработка аннотаций никуда не денется.
Интеграция инструментов в порядке. Последние версии основных IDE содержат параметры для настройки процессоров аннотаций и интеграции их в процесс сборки. Инструменты сборки основного потока также поддерживают обработку аннотаций, где maven все еще может вызвать некоторые проблемы.
Однако при тестировании я обнаружил большую проблему.Все тесты являются косвенными и так или иначе подтверждают конечный результат обработки аннотации. Я не могу написать никаких простых модульных тестов, которые просто подтверждают простые методы, работающие с TypeMirrors или другими классами, основанными на отражении. Проблема в том, что нельзя создать экземпляры классов этого типа вне цикла компиляции процессора. Я не думаю, что Sun действительно имела в виду возможность тестирования при разработке API.