dev_troy Oct 4 2015 at 20:40

Обработка аннотаций в процессе компиляции

10 min

35K

e-legion corporate blogJava*Development of mobile applications*Development for Android*

+16

Comments 17

rogrom Oct 4 2015 at 22:09

Спасибо, интересно, продолжайте!

rogrom Oct 4 2015 at 22:15

Столкнулся с проблемой обфускации: все Annotation style библиотеки (тот же ButterKnife) просят добавлять исключения для Proguard. В итоге после обфускации все инжектируемые поля и bindable методы не переименовываются, а это способствует RE. Кто-нибудь знает, как с этим бороться?

zagayevskiy Oct 4 2015 at 23:32

Что такое RE?

werktone Oct 4 2015 at 23:54

Reverse engineering

dev_troy Oct 5 2015 at 08:37

Никак. Сгенерированные в процессе компиляции классы, используются рефлексией в рантайме. Кстати, хак со встраиванием класса в иерархию наследования решает эту проблему, ProGuard спокойно может обфусцировать все что можно =)

zagayevskiy Oct 5 2015 at 16:09

Proguard это не обфускатор, а минификатор. Минификация усложняет RE незначительно.

KamiSempai Oct 5 2015 at 02:33

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

Artem_zin Oct 5 2015 at 04:39

Статей на английском достаточно много + есть записи докладов Вортона и других людей + можно изучать исходники библиотек, которые используют Annotation Processing.

Artem_zin Oct 5 2015 at 04:49

«Классная» идея заюзать полуприватный, недокументированный апи компилятора (который может менятся в любом апдейте JDK) и менять существующий код ради ооочень слабого профита в виде private поля, еще и в иерархию наследования вклиниваться.

Что может пойти не так?)

dev_troy Oct 5 2015 at 08:31

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

Artem_zin Oct 5 2015 at 15:13

Ну ок ок :)

iamironz Oct 5 2015 at 10:13

Отличная лекция на droidcon и её перевод в текстовый вариант, спасибо!

dougrinch Oct 5 2015 at 14:26

Напрягает выпиливание private. Ведь если в соседнем классе обратиться к этому приватному филду, то, несмотря на ругань ide, все скомпилируется. Вопрос: зачем вообще убирать private? Почему нельзя обойтись setAccessible(true) чтобы убрать проверку доступа не везде, а только где это необходимо.

dev_troy Oct 5 2015 at 14:59

setAccessible — это фича рефлексии. Мы же от рефлексии пытаемся уйти.

kemsky Oct 5 2015 at 19:14

Для этого уже написан apt-plugin, можно еще посмотреть AspectJ для андроида.

dev_troy Oct 5 2015 at 19:36

Безусловно, придумано уже много чего. Но APT, который появился фактически вместе с релизом аннотаций, объявлен ораклом как устаревший инструмент. А aspectJ работает схожим образом: модификация кода. Только использовать надо кастомный компилятор. Ещё ASM есть, lombok и еще куча всего.

kemsky Oct 5 2015 at 21:15

Я неправильно выразился, apt-plugin — вспомогательный инструмент для библиотек, которые используют компайл-тайм аннотации и кодогенераторы, apt не значит, что используется депрекейтед апи, это просто аббревиатура. Сами библиотеки(android annotations, dagger и, кстати, lombok) используют новое апи компилятора, как и написанов статье.

По уровню магии меня с большего устраивает android annotations, поэтому я передумал делать что-то свое, хотя первое время очень хотелось. Скоро в android annotations добавят возможность подключать свои плагины, а значит можно будет добавлять поддержку библиотек по желанию и с минимумом усилий. В идеале хотелось бы, чтобы магия была полностью скрыта — никаких классов с underscore в конце.

AspectJ хорош тем, что не нужно велосипедить, все уже написано, подключай и используй, если необходимо. Последний пример как раз неплохо ложится на аспекты.

ASM и lombok врядли популярны на андроиде.