Java7で予定されていたプロパティ構文案の見送りは正解

見送りがアナウンスされてから時間が経っているので
今更感がありますが書いておきます。

スコープ修飾子 property 型 フィールド名 set|get

この構文はそもそも気持ち悪く、言語としての整合性に無頓着なC#から
そのまま拝借してきたようにしかみえないので、Java7で採用されないのが
正解だと思います。

(採用されてしまうと取り返しがつかないので、採用されなくて正解。)

プロパティ構文で意図しているのはフィールドに対してアクセス
に関する許可の範囲を示す属性を付加することだと理解しています。

Javaではフィールド等に対して属性を付加するためにアノテーション(注釈)
が既に導入されています。

修飾子で属性を追加していくことは美しくない？ので、より柔軟に
フィールド等に対して属性を付加することのできるアノテーションが
導入されたのだと理解しています。

上記の構文はアノテーションがあるにも関わらず無いもののように扱い、
態々修飾子や文法(ローカルキーワード？等)を新規に追加していて、
言語としての一貫性を壊すようにしか見えません。

何故、一貫性を壊す上記の構文がJSRに提案されたのか疑問です。
提案者に美的センスがないとしか思えません。

上記の構文の一貫性のなさがJava7でプロパティ構文の導入が
見送られる原因だと思います。

(ローカルキーワード？、上記の構文以外のJava7で提案されていた
構文拡張案では利用されていないようにみえる。
上記の構文のためだけにローカルキーワード？が導入され、
それが後付で今後の構文拡張で利用されるようになるのも
気持ち悪い。)

上記の構文ではなく、下記のほうがJavaの既存の構文との
整合性が取れていてJava流ではないかと思います。

@property("set|get")
スコープ修飾子 型 フィールド名

コンパイラやVMで読み取ることを意図して言語仕様内で予約された
アノテーション(@override等)は既にいくつかJava言語仕様で規定
されているので、仕様的に違和感はないと思います。

プロパティ構文相当の機能のうち、上記の@property相当の機能は
構文としてではなく、言語仕様予約のアノテーションとして
言語仕様に追加するのがベストな選択肢ではないかと思います。

アクセサの変更に関しては例えば

interface Accessor{
　set(T t);
　T get();
}

のようなインターフェイスを継承したクラス AccessorImplを準備して

@accessor(AccessorImpl)
@property("set"|"get")
スコープ修飾子 型 フィールド名

のようなイメージでアクセサを付け替える？(AOPする?)ことが
できるようにするのもありだと思います。

自分としては以下に書く方法がアクセサの変更に関しては
よりベターなのではないかと思います。

(あとで書きます。)

推敲中。