アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
開発手法、検証手法以前に (スコア:3, 参考になる)
あとはstaticの認識と。
Re:開発手法、検証手法以前に (スコア:1)
staticを使ってのパフォーマンス向上は諸刃の剣のはずなのだけど…やたらとpubli staticなsetter/getterを作りたがるPGがたまに居て…_no
Re:開発手法、検証手法以前に (スコア:0)
staticメソッドから非staticな変数へはアクセス出来ないし。
Re:開発手法、検証手法以前に (スコア:2, 参考になる)
public class Configuration {
private static String s1;
public static void setS1(String s){
s1 = s;
}
public static String getS1(){
return s1;
}
}
こんなの書いてきた人います。しかも複数…。
Re:開発手法、検証手法以前に (スコア:1)
『newしないとクラスが使えないようだが？』
『staticなんて飾りです。偉い人にはそれが分からんのです』
まあ、Math classみたいにそれ自体にデータを持たない場合の
static methodはありだし、システム全体の排他制御のための
オブジェクトなど複数オブジェクトがあると困るような場合は
Singletonが正しいアプローチだけどさ。
なんにしろ、設計に存在しないグローバル変数はバグの元。
Re:開発手法、検証手法以前に (スコア:0)
そういうグローバル変数に触れていないメソッドであることを、
コンパイラにも分かる形で宣言できたらいいのに、と思ったことがあります。
例えば、java.lang.Integer の parseInt(String) なんかは、入力された引数のみ が
戻り値に影響を与えるべきメソッドですが、本当に大丈夫か、と疑い出したら、
ソースを追ってみるしかないです。
Re:開発手法、検証手法以前に (スコア:1)
＞別なスレッドの影響を受けちゃうような実装に＊なっていない＊ことを、
＞表明できる仕組みがあればいいのになぁ
コンパイラに対してってのは難しいですねぇ。
コンパイラに宣言する以上はコンパイラは実装をチェックする
必要がありますが、そのメソッドから呼び出される処理は全部
再帰的にチェックしなくてはいけません。
流石にコンパイラの手に負えないですね。クラスファイルの
形式にも変更が必要になります。
変に採用すると
「ちゃんとスレッドセーフだけど、コンパイラが文句を言うので表明できない」
なんてケースが出てきそうです。
＞そういうグローバル変数に触れていないメソッドであることを、
＞コンパイラにも分かる形で宣言できたらいいのに
グローバル変数云々だけならコンパイラにもできそうですが、
スレッドセーフかどうかはとは別問題なので、役立つ場面は
少なくなります。
ありがちなパターンを見つけ出したいなら、FindBugsなどの
ツールを使って「バグっぽい」コードを警告してもらうのが
限界でしょう。
それ以上のことは、JavaDocの表明を信じる or 自分でソースを追いかける しかないです。
Re:開発手法、検証手法以前に (スコア:1)
Re:開発手法、検証手法以前に (スコア:1)
ただ、アノテーションは「スレッドセーフをコンパイラに対して表明する」ではなく、「ツールや
他の開発者にそう主張している」ですから、JavaDocでの表明と本質的な違いがないです。
・他の開発者に伝えるのなら、JavaDocで表明する
(フォーマットを統一したりしたいなら-tagオプションやTaglet、Doclet)
・コンパイラやツールがスレッドセーフの保障をするのは無理
・作成者の表明(JavaDocやアノテーション)を疑うならソースを追うしかない
が本題です。