[jfriends-ml 11806] Re: @deprecated タグ (Re: 本日の議事録)

[Toru TAKAHASHI <tooru6.takahashi@xxxxxxxxxxxxx>]

高橋（徹)です。

   ""TAKAHASHI, Tomohiro" <t_takahashi@xxxxxxxxxxxxxx>"さんは書きました：
>   私は、肥大化というよりは、EJBのように、Javaのソースコードのレベルで
> 互換性があるようなものを記述する場合に、サーバベンダーの中にはそのベン
> ダー独自のアノテーションを提供するもが現れて、ソースコードのレベルでの
> 互換性が失われるようになったれ、とても嫌ですね〜。(^^;;;;;;;;;;;;
アノテーション自身の標準化が重要ですね。独自アノテーションが氾濫したら
目も当てられない。
幸い、J2EEという縛りがあるので、心配する事態にはならなさそうです。

昨日の「丸山先生レクチャー」と、本日の「Hands on Lab」でアノテーション
漬けになっていました。
アノテーションが何に使えるか、思いつきレベルの発想を挙げます。
まだアノテーションの限界が分かっていないので、実現不可能なものも
あるかもしれません。（Aspectと結びつけるのかな？）
・事前条件・事後条件アノテーション
  事前条件検査、事後条件検査コードを生成する
・RMIリモートインタフェース抽出アノテーション（J2EEではEJBのリモート
  インタフェース生成用に@Remoteを使うようです）
  RMI-IIOPのビルド手順簡素化に使えるかもしれません
・各クラスのバイトコードにバージョン番号を埋め込むアノテーション
 （C言語で言えば、#pragma ident みたいな）
・Getter/Setter生成制御アノテーション
  フィールドだけ記述して、アノテーションでSetter/Getterの有無とアクセス
  修飾子を生成させる
・JUnitでテストケースの入力値を多種類用意するときに、アノテーションで
  指定してしまう。境界値試験だと、境界の外2つ、境界2つ、内部の代表値1の
  ５つのテストメソッドが必要になりますが、違いは入力値と期待値だけなので
  自動生成できないかな〜・・・。
・JUnitでテストケースから日本企業受けするきれいな帳票を生成するための
  アノテーション。（テスト手順書、成績書）


---
TAKAHASHI Toru