2all agains annotations, 
не знаю не знаю ... в JPA ведь уже давно реализованы такие аннотации и они пользуются большой популярностью из-за своего удобства.


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


Это сообщение отредактировал(а) v2v - 3.10.2008, 13:19

За свою практику в C# я регулярно пользуюсь всего одной аннотацией (в .net они называются атрибутами), которая к тому же не влияет на выполнение или компиляцию кода: DebuggerStepThrough - говорит отладчику, что не надо заходить внутрь метода.
Помимо прочего эпизодически приходилось пользоваться атрибутами для контроля сериализации: вроде NonSerializable - аналог ключевого слова transient в Java, и ещё какими-то на эту тему, сейчас уже не вспомню.

v2v, ты прав, никто не заставляет так писать -- но ведь, как я уже сказал: код приходится читать чаще, чем писать. А читать подобную ересь тяжело.

В .net проблема "неприсвоения" null в некором роде решена просто, там есть структуры (value type), которые не могут принимать null (хотя основное назначение value type совсем другое). Простейший пример структуры - примитивные типы вроде int, double и т.п.
С другой стороны описанная проблема вызова ToString(), когда переменная равна null тоже в некотором роде решена оператором ?? в C#, то есть я могу написать (something ?? "zzz").ToString() и тогда в случае если something == null будет использована строка "zzz"
Но это всё частные случаи -- просто вспомнилось 

Добавлено @ 13:31
Возможно, меня смущает плохая читаемость аннотаций в Java из-за их синтаксиса. В .net принято писать [BlaBlaBla] вместо @BlaBlaBla и это мне нравится, потому как @BlaBlaBla у меня блоьше ассоциируется с переменными в SQL.

Это сообщение отредактировал(а) Дрон - 3.10.2008, 13:36

Когда аннотации к месту они хороши. В JPA, EJB3, для декларативной демаркации транзакций, для IoC в spring и guice, для fine-grained security, при назначении аспектов, для сериализации JAXB, для вебсервисов. То есть в тех местах, где из задача ортогональна функционалу основного кода. А вот когда аннотации начинают влиять на исполнение самого кода или даже компиляцию - это имхо перебор.

Это сообщение отредактировал(а) fixxer - 3.10.2008, 13:37

В точку!

И, кстати, да -- хороший пример аннотации: декларативные транзакции, или декларативное security, мне правда не приходилось им на практике пользоваться, но "в домашних условиях" тестировал 

Вообще-то аннотации в первую очередь для "влияния на компиляцию" и создавались :whlistle А как раз аннотации, обеспечивающие транзакции/безопасность/etc - это и есть аннотации, влияющие на исполнение. Что-то господа ортодоксы ломанулись в другую крайность  

Это сообщение отредактировал(а) w1nd - 3.10.2008, 13:45

всё-таки был смысл в поднятой моей теме   зачёт    а то тут набросились на меня со всех сторон и пинают ногами  

хоть что-то новое узнали   



человек говорящий это явно болеет самомнением.. 

---

тынц 

Все Exception должны быть за декларированы, в том числе и RuntimeException. И если разработчик базового класса, решил что этот метод можно не реализовывать, то ему надо просто за декларировать что метод може выбрасывать UnsupportedOperationException и проблема решена (в Collection API полно примеров такого подхода). Разница между:

и

не настолько велика, чтобы ради неё менять язык.

А если тебе приходится в 100 классов реализовывать пустые методы и просто выкидывать в них исключение, то это опять же означает только плохое проектирование. Например в том же Collection API можно было бы сделать, два интерфейса List и унаследованный от него MutableList (при условии конечно, что востребованность ummutable листов было бы велика).




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

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



Наличие или отсутствие анотации @Entity никаким образом не влияет на возможность мною использовать этот бин, ни на исполнение кода этого бина. У меня может не быть никакой JPA, никакого персистанса вообще. Тем не менее я вполне могу использовать этот бин для каких-то своих черных целей.



То же самое. Эти аннотации предоставляют информацию другим частям проекта. Они инфраструктурные.

Да, пожалуй, я тут перебрал. 

я бы так не сказал...
расскажу про грабли, о которые я сильно ударился, буквально вчера.
Делал я рефакторинг в своём проекте..
Есть у меня дао классы , которые работают через hibernate c бд - сохраняют, удаляют, обновляют , получают записи  :



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

создал:

Ну и после расширил свои дао-классы этим родителем.

Запустил самописные тесты, которые перед этим выполнялись корректно: вроде бы всё Ок, данные пишутся, читаюсь, удаляются, обновляются ... ошибок нету. Но , немного спустя , заметил что в промежуточную таблицу, которую создаёт хибернэйт для отношения много-к-много никакие данные не сохраняются! Тоесть, не сохраняется именно отношение много-к-много ... это было очень странно, потому что во всех остальных отношениях (1-1,1-n,n-1) данные сохранялись правильно.

В общем, очень долго копал, перерыл весь свой код, написал кучу дополнительных тестов... ничего не помогло... Причина мне до сих пор не совсем понятна, я не поставил аннотации 

перед объявлением своего абстрактного класса!!!
ПОсле добавление этих самых аннотаций, всё стало на свои места... вот теперь скажите что аннотации не влияют на исполнение кода..

Аннотации не влияют на исполнение кода на уровне JVM (а именно про это и говорит ТС). Но никто не мешает построить свою логику, основанную на данных из аннотаций.

а возможно ли в аннотацию в качестве параметра передать переменную и как? 

Аннотации - это статическая информация, доступная во время компиляции.

Не обязательно только во время компиляции

Нет, вы цитату привели совсем не о том. Атрибуты аннотации должны быть вычислябельны на этапе компиляции.