[jfriends-ml 11416] Re: Java 1.5 Tiger : A Developer's Notebook

[murayama <locutus@xxxxxxxxxxxxxxxx>]

村山@netgeneです．

> JLS3.0のドラフトには次のように書かれています。
中略
> つまり、言語仕様です。ただし、この言語仕様をどのように実装するかは、実装
> 依存です。この点に関しては、次のように解説されています。
どうやら仕様ではなく実装というのは早とちりだったようです．

が，

それにしても妙な仕様ではあると思います．こんな所に同期処理，或いは
初期化時(VM起動時やクラスのロード時等)に前もって生成しておくような
仕様を入れるのは，あまりお奨めできません．

しかも重要なのは，この仕様のメリットがほとんどないことです．
＃レガシー=コレクションのsynchronizedメソッドのようなもの．
＃致命的リスクとは限らないが，メリットが全くないので採用する意味がない．
＃さてboxingにおける同期のメリットはいかがなものだろう？

「-128 and 127の範囲でのみ常に同一性が保証される」
というのが，はたしてboxing/unboxingで広く使われるでしょうか？
boxing/unboxingの性質上，インスタンスとしての性質を使用するプロ
グラミングスタイルは使わずに基本的に「値」として使うのだから，==
による比較は少なくなると考えられます．
＃intなどの場合はさらに厄介で，値によって挙動が変化する．

パフォーマンス重視というのなら，そもそもboxing/unboxingを使う
こと自体が間違いです．


あと互換性についてはどうなんでしょう．

今の所はAPI仕様には
「-128 and 127の範囲でのみ，常に同一性が保証される」
とは書いていないようなのです．

これがない限りは，クラスファイルレベルでの将来の互換性は保証
されないのでは．


私だったら言語仕様の方を変更したいですね．

とりあえず今は「保証されない」ということにしておいて，後から
保証されるに変更しても互換性の問題はないですが，その逆は致命的
です．必要かどうかもわからないのに「保証する」としておくと，
取り返しの付かない失敗になるかもしれません．

＃このままで行くと，何年かすればVector，HashTable,StringBufferの
＃同期のように，厄介者扱いされるようになったりして．