2015-01-24 2 views
3

Я собираюсь создать индекс (даже простой список, хранящийся в файле) классов, аннотированных определенным типом аннотации во время компиляции с помощью обработчика аннотации, чтобы ускорить поиск аннотированных классов во время выполнения.Java, Является ли индекс аннотированных классов во время компиляции с помощью Обработчика аннотаций хорошей практикой?

Итак, это хорошая практика? Есть ли недостатки? Если это так хорошо, как мне кажется, почему нет многих библиотек, чтобы сделать это простым способом (единственный, который я нашел, - Class Index)? Вместо этого для обработки времени выполнения так много?

+1

Это звучит как [преждевременная оптимизация] (http://c2.com/cgi/wiki?PrematureOptimization) для меня. Вы проводили тесты? –

+0

ClassIndex сделал несколько интересных тестов, я сам не сделал. Это может быть преждевременная оптимизация, но вопрос остается. Думаю, это также важная проблема дизайна моей библиотеки. –

+0

Цитата из вашей ссылки * скорость Java ** загружает загрузочные ** **, сколько раз (обычно) вы могли бы сказать, что ваши (или ваши пользователи) приложения (ов) обычно загружаются в течение одного прогона? Наконец, «плагин Reflections Maven» выглядит так же, как и почти (на этом единственном опубликованном эталоне) ... –

ответ

1

Я думаю, что главными недостатками является то, что это сложнее. Обработка аннотаций - это совершенно новый API и концепция, о которых многие разработчики не знакомы. API Reflection проще и более известен. Обычно вы можете выполнять одни и те же задачи во время выполнения.

Если более высокая производительность запуска имеет решающее значение (что редко бывает), то, возможно, стоит добавить сложность.

Я бы не стал доверять критериям. Они заявляют, что «classpath size был установлен в 121MB» - произвольное значение, которое делает любое сравнение с жесткой кодировкой или обработкой времени компиляции совершенно бесполезным. Почему вы все равно хотите отсканировать весь путь к классу? Сканирование только классов разработчиков было бы более разумным в большинстве случаев.

Многие фреймворки используют конфигурационные файлы или имеют API для ограничения классов или пакетов, которые необходимо отсканировать. Это значительно увеличивает время запуска.

почему не существует множество библиотек, чтобы сделать это

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

Я бы не сказал, что это хорошая или плохая практика. Используйте этот метод, если он соответствует вашим потребностям. Я бы не добавлял много сложностей ради запуска нескольких миллисекунд.

+0

Спасибо за заметный ответ, очень полезно получить более широкий обзор. Думая об этом, я на самом деле нашел недостаток в индексировании времени компиляции, что является недостатком применимости к подключаемым библиотекам, таким как реализация абстрактных фабрик и SPI. Я не уверен, должен ли я поставить это в ответ на мой собственный вопрос. –

1

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

Преимущества:

  • Индексация обработка с использованием аннотаций на основе официального JSR 269. С другой стороны, сканирование на пути к классам Java опирается внутренностей. Общеизвестно, что ClassLoaders не имеют API для извлечения списка аннотированных классов. Но что более удивительно, так это то, что общий ClassLoader не позволяет перечислять папки и файлы JAR, откуда он пытается загрузить классы. Сканеры Classpath предполагают, что единственным загрузчиком классов, используемым для загрузки классов, является URLClassLoader, который позволяет извлекать URL-адреса источников для сканирования с использованием getURLs() method.
  • Есть среды, где обычные сканеры классов маршрутов do not work, то есть на Android, где используется формат исполняемого файла Dalvik.
  • Постоянная сложность во время выполнения позволяет быстро индексировать компиляцию.
  • Проект Jigsaw планирует принести annotation detection to Java. Существующие требования также указывают на то, что индексация времени компиляции является жизнеспособной для нее. Он даже вводит метаиндотацию @Indexed с той же целью, что и @IndexAnnotated в библиотеке ClassIndex.

Недостатки:

  • JSR 269 плохо поддерживаются через Java компилятор и инструменты. В ранних версиях javac было несколько ошибок. У пользовательского JDT-компилятора Eclipse есть еще больше ошибок, и он не поддерживает автоматическое обнаружение обработчиков аннотаций. ClassIndex включает обходные пути для многих из этих проблем.
  • Сканирование по классу является стандартом facto и очень хорошо поддерживается.
  • Время загрузки приложения редко является узким местом, о котором можно беспокоиться.
1

Возможно, вам интересен подпроект JBoss WildFly: Jandex.

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

Jandex звучит так же, как и вы.

Смежные вопросы