Есть такое средство, чтоб на основании каких-нибудь аннотаций в классе,
могло автоматически добавить в код этого класса дополнительные поля и методы?

Здравствуйте, tnikolai, Вы писали:

T>Есть такое средство, чтоб на основании каких-нибудь аннотаций в классе,
T>могло автоматически добавить в код этого класса дополнительные поля и методы?
Вагон и маленькая тележка средств. Какая именно задача стоит?

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, tnikolai, Вы писали:

T>>Есть такое средство, чтоб на основании каких-нибудь аннотаций в классе,
T>>могло автоматически добавить в код этого класса дополнительные поля и методы?
B>Вагон и маленькая тележка средств. Какая именно задача стоит?

Странно, я вот читал, в Effective Java, что использование анноаций не должно влиять на сам код, лишь на его обработку,возможно вызов.
Может я не правильно понял, но могу привести пример.

Здравствуйте, Аноним, Вы писали:

А>Странно, я вот читал, в Effective Java,
Последняя инстанция, да.

А>что использование анноаций не должно влиять на сам код
"не должно" или в "большинстве случаев не влияет" ?

А>, лишь на его обработку,возможно вызов.
А вот, например, есть такие аннотации, которые только при компиляции видно. Они для чего?

А>Может я не правильно понял, но могу привести пример.
Пример чего? Какая логическая подоплека того что "аннотации не должны влиять на байткод". "Байткод" же имеется ввиду?

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, tnikolai, Вы писали:

T>>Есть такое средство, чтоб на основании каких-нибудь аннотаций в классе,
T>>могло автоматически добавить в код этого класса дополнительные поля и методы?
B>Вагон и маленькая тележка средств. Какая именно задача стоит?

Есть класс, который соответствует таблице в базе данных. И нужно чтоб автоматически сгенерировался дополнительный код для Select/Insert в базу данных.
Желательно чтоб прямо в в код класса новые дополнительные поля и методы добавились.

Здравствуйте, tnikolai, Вы писали:

T>Есть класс, который соответствует таблице в базе данных. И нужно чтоб автоматически сгенерировался дополнительный код для Select/Insert в базу данных.
T>Желательно чтоб прямо в в код класса новые дополнительные поля и методы добавились.
Ох и на скольскую дорожку вы вышли с такой постановкой задачи. Кодогенерация это большое зло
Гугл знает кучу фреймверков:
https://www.google.com/search?q=java+annotation+based+code+generation

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Аноним, Вы писали:

А>>Странно, я вот читал, в Effective Java,
B>Последняя инстанция, да.

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

А>>что использование анноаций не должно влиять на сам код
B>"не должно" или в "большинстве случаев не влияет" ?

А>>, лишь на его обработку,возможно вызов.
B>А вот, например, есть такие аннотации, которые только при компиляции видно. Они для чего?

А>>Может я не правильно понял, но могу привести пример.
B>Пример чего? Какая логическая подоплека того что "аннотации не должны влиять на байткод". "Байткод" же имеется ввиду?

Вы учтите, что книгу читают люди с разным уровнем, и, возможно мой не самый высокий, и что то я понял совсем не так, что имелось ввиду в книге.

Effective Java, стр. 171.
The Test annotations have no direct effect on the semantics of the Sample
class. They serve only to provide information for use by interested programs.
More generally, annotations never change the semantics of the annotated code, but
enable it for special treatment by tools such as this simple test runner.

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

Здравствуйте, Аноним, Вы писали:

А>Может и не последняя, но одна из эталонных. Не во всем можно соглашаться, но если и спорить то аргументированно.
Вот и я о том же. Какие ваши аргументы? Фраза "в книжке написано" это мой любимый момент в Space Jam

"Eh, not so fast Doc," said Bugs as got the chains off his body. "You can't just turn us into slaves. That would be bad. You got to give us a chance to defend ourselves."
"Oh yeah? Who says?" Pound aimed his gun at Bugs as the rabbit showed them a book that said 'How to draw Cartoon Characters' but Bugs changed the title that said 'How to capture Cartoon Characters.' The aliens looked through the book and found a piece of paper taped to a page that said 'Give them a chance to defend themselves.'
"Do we have to?" asked Bang.
"It's in the rule book," replied Nawt.

А>И почему вы так вскипаете вообще?
Я спокоен как танк. Ни восклицательных знаков, ни заглавных букв, ни выделения жирным. С чего вы взяли что я вскипаю?

А>The Test annotations have no direct effect on the semantics of the Sample
А>class. They serve only to provide information for use by interested programs.
А>More generally, annotations never change the semantics of the annotated code, but
А>enable it for special treatment by tools such as this simple test runner.
Это скорее неудачаня трактовка. Вот что говорит документация по этому поводу.
http://docs.oracle.com/javase/1.5.0/docs/guide/language/annotations.html

Annotations do not directly affect program semantics, but they do affect the way programs are treated by tools and libraries, which can in turn affect the semantics of the running program. Annotations can be read from source files, class files, or reflectively at run time.

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

А>Но привидите пример, когда аннотоации нужны не для кодогенерации,как в посте спрашивают, а реально для добавления новых методов или полей класса.
Та сейчас всё JEE и много в JSE так работает. Парсит аннотации и генерит кучу кода. Например, JAXB сериализация. Сейчас, конечно, ушли от того чтобы генерировать код в клиентские классы. Но ещё в JAXRPC было иначе. JiBX создаёт новые методы сериализации прямо в клиентских классах. Правда, я за ним не слежу. Парсит ли он при этом именно аннотации — не знаю. Но ведь не суть важно где именно лежат метаданные.

А>И при этом использование аннотоаций в этом случае будет являеться — наиболее оптимальным решением.
А в Java нет других родных средств расставлять метаданные.

Здравствуйте, Blazkowicz, Вы писали:
...
B>... Кодогенерация это большое зло

Кстати, почему? Был неудачный опыт использования или есть другие причины?

Здравствуйте, Аноним, Вы писали:

А>Вы учтите, что книгу читают люди с разным уровнем, и, возможно мой не самый высокий, и что то я понял совсем не так, что имелось ввиду в книге.

А>Effective Java, стр. 171.
А>The Test annotations have no direct effect on the semantics of the Sample
А>class. They serve only to provide information for use by interested programs.
А>More generally, annotations never change the semantics of the annotated code, but
А>enable it for special treatment by tools such as this simple test runner.

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

Тут совсем другое написано. А именно аннатации никогда не менают (не должны менять) смысл кода. А методы и прочую ерунду добавлять не возбраняется.

Здравствуйте, tnikolai, Вы писали:

T>Есть такое средство, чтоб на основании каких-нибудь аннотаций в классе,
T>могло автоматически добавить в код этого класса дополнительные поля и методы?

Безусловно. Посмотрите, например, на AspectJ.

Здравствуйте, A13x, Вы писали:

A>Кстати, почему? Был неудачный опыт использования или есть другие причины?
Причин масса, вот только на вскидку
— код нужно не забывать генерить. Т.е. если у меня на сервере работает класс, обработанный кодогенератором, то мне нужно проходить этап кодогенерации. Просто подменить такой класс на сервере я не могу.
— ошибки кодогенератора глобальны — влияют на все фичи проекта. Вот автор разрабатывает слой работы с БД. И любая ошибка кодогенератора одновременно проявляется в любой фиче приложения.
— ошибки кодогенератора нельзя править на месте — вот мне генератор нагенерил такой код, а мне именно в этом месте нужен другой. Для этого мне надо править кодогенератор. В большинстве хорошо спроектированых фреймверков это решается. Всегда где-то можно переопределить метод, или заменить локально нужную функциональность. С кодогенератором такое сложнее.
— для отладки ошибок кодогенератора, нужно иметь под рукой нагенеренные исходники. А если вдруг генерировался сразу байткод, то отладка идёт лесом.

Раньше имело смысл использовать кодогенерацию, т.к. генеренный код выдаёт хорошую производительность, в сравнении, например, с рефлексией. Но рефлексия сейчас хорошо оптимизирована. К тому же генерация SQL кода вряд ли может являтся узким местом в производительности.
Ещё кодогенерация имеет смысл для создания некоторой черновой структуры, как например, Spring Roo. Но только в случае дальнейшего отказа от постоянной кодогенерации. Ни Spring Roo, ни Seam (не совсем кодогенаратор, но идеологически близок) не выстрелили и массово не используются. Именно по причинам указаным выше.

Ищите в гугле и на rsdn, вопрос этот уже много раз обсуждался.

Здравствуйте, Blazkowicz, Вы писали:

Не очень хорошо оптимизирована, по крайней мере ее использование всякими фреймворками. Был как то раз затык на методе java.lang.reflect.Field.doSecurityCheck(Object obj) из за слова synchronized(java 1.6)

Ну и с хибером иногда можно на грабли налететь если использовать прокси.

Здравствуйте, PZI, Вы писали:

PZI>Не очень хорошо оптимизирована, по крайней мере ее использование всякими фреймворками. Был как то раз затык на методе java.lang.reflect.Field.doSecurityCheck(Object obj) из за слова synchronized(java 1.6)

Судя по openjdk 7 уже должны были исправить. И, да. У нас теперь есть openjdk, если надо чего где подкрутить.

Здравствуйте, tnikolai, Вы писали:

T>Здравствуйте, Blazkowicz, Вы писали:

B>>Здравствуйте, tnikolai, Вы писали:

T>>>Есть такое средство, чтоб на основании каких-нибудь аннотаций в классе,
T>>>могло автоматически добавить в код этого класса дополнительные поля и методы?
B>>Вагон и маленькая тележка средств. Какая именно задача стоит?

T>Есть класс, который соответствует таблице в базе данных. И нужно чтоб автоматически сгенерировался дополнительный код для Select/Insert в базу данных.
T>Желательно чтоб прямо в в код класса новые дополнительные поля и методы добавились.

Вот проект, где кодогенерацией (в рантайме) пишется equals и hashcode.
https://github.com/Fuud/jautohash

Здравствуйте, tnikolai, Вы писали:

T>Есть такое средство, чтоб на основании каких-нибудь аннотаций в классе,
T>могло автоматически добавить в код этого класса дополнительные поля и методы?

Имхо самый простой, понятный и надёжный способ — постпроцессинг .class-файла. Т.е. компилируете, потом натравливаете на получившееся ваш инструмент, который сканирует и переписывает нужные .class-файлы. При необходимости легко пишется плагин к maven-у, ant-у.

Другие варианты — Java Annotation Processing API (я не знаю, что это такое и как оно работает, когда я пытался разобраться, я так и не смог "завести" его, осталось впечатление недоработанной технологии, на практике нигде не видел её применения кроме project lombok), кастомный classloader (если есть возможность управлять classloader-ами), java agent (если есть возможность управлять запуском java).

У всех вариантов проблема с интеграцией с IDE, если нужно генерировать новые методы и т.д., то IDE их не увидит просто так.