読書会(Effective Javaプログラミング言語ガイド)第5議事録

読書会(Effective Javaプログラミング言語ガイド)第5回議事録

EffectivaJava 第５回議事録 2002年 9月21日 @田町
　高橋徹　高橋智　布留川　山城　新井　瀬山　宮本　村上
　天野　石黒　根本（記）　鈴木

P155 より
項目38
■  昔はFQCNは大文字で書いていたが、いまは全て小文字
■  全世界ユニークな名前付けで、 jp.gr.java_conf.* というpackage名がもらえる。
　　IAJがドメイン管理している。自分だけのpackage名を持ちましょう！！
■  boot strapより前に読み込ませれはせ java.lang.* などもimport可能と思われる、
　　通常はjava.*のimportは拒絶される。
■  ハンガリアン表記は、C#はハンガリアンは推奨していない。
　　FQCNでしか本当の形はあらわせないのでオブジェクトに
　　ハンガリアンするのはもうあきらめましょう。
■  isXXXXは使わない方向にしましょう、非英語圏からみればgetXXXで十分。
■  com.speed()は field直結であることがイメージできない
　 com.getSpeed()なら fieldに対するgetterであると感じられる。
　この例はよろしくない。
■  asXXXX()は使わない。 toXXXXX()と区別つかない。
■  getInstance()はsingletonのイメージがあるが、単にインスタンス取得の意味でしかない。
項目39
■  P160上、この推奨利用方法は、スレッドセーフではない、これでいいのか
　for (Iterator i = collection.iterator(); i.hasNext();) {
　 Foo foo = (Foo) i.next();
  ............
　}
　むしろ
　try {
　  Iterator i = collection.iterator();
　  while(true) {
　    Foo foo = (Foo )i.next();
　    ....
　  }
　} catch (NoSuchElementException e) {
　}
　はたとえどんなに遅くとも、平行操作に対する耐性が有る。
　他のスレッドからiteratorをいじられても感知できる。
　しかし一方
　event handlerの通知モデルのように、snapshotを撮ってiterateすればよいともいえる。
　arraycopyでコピる負荷はあるが、これならiterator自体はまわせる。
　ただしobject消滅は常に確認すべき。
　これはObserverパターンのかかえる基本的課題。
項目40
■   java1.4から　chained error処理が可能。
項目41
■　 memory errorは　システムエラーなので exceptionの中でnewしても問題ない。
　　仮にメモリー不足報告オブジェクトを生成しようとしてもその前にVM死んでいる。
■ runtime　exceptionは　printStackTraceされるので、e.printStackTraceしなくてもよい
■ cloneは必ずcloneNotSupportedExceptionおきえるので必須。
項目42　　
■  ArithmeticException = 0で割った　tan(90度)とか。
■  javaプログラマーはトレースのためにifdefをほしがってはいけない、
　　アスペクト思考でtraceを挿入すべき。
項目43
項目44
■  ConcurrentModificationExceptionは元に戻るfixできない。
■  interfaceのjavadocの @throw に要件を書かれたらその実装者はかならず
　　そういうthrowを実装しなくてはいけない言語使用にしたほうが厳しくてよいかも。
項目45
項目46
■　ConcurrentMidificatioExceptionは中間状態に値がセットされることがあるので元に戻せない。
項目47
■　printStakTraceは　System.oerr.println()　なのでマスクすればfileへのリダイレクトも可能
　　製品版にするときはスタックはファイルに落として画面は、「混雑しております」
　　くらいにしておいてトボけるのが吉。
項目48
■　return nextSZerialNumber++は２つの操作の合体した単項演算子なので、
　　アトミック操作ではない。　<-- 間違いそう、要注意。
■　P182. double-checked lokingがなぜ動かないか。
private static Foo foo = null;
public static Foo getFoo() {
  if (foo == null) {             <---- A
     synchronized (Foo.class) {
     if (foo==null)
     foo = new Foo();
     }
  }
  return foo;                    <---- B
}

fooはまだ出来上がってはいないが、nullではなくなっている時、Aは不成立して
B点で不完全なfooが返っていく。という理解であったが。
しかし、そのうちfooは完成してしまうのでは？
double-checked locking についてお勧めＵＲＬ、これを見るだけで十分。
他にもwww.javaworld.comにもいろいろ書いてありますが、すべてこの記事のサブ
セットです。
    http://www-6.ibm.com/jp/developerworks/java/020726/j_j-dcl.html
■　そもそもnullの評価で、例外に飛ぶこと以外やっていいのか、
　　null-->インスタンス化-->nullのタイミングはJVMに依存しているのでは。
■　P183 上　いつnewするのか
  // 怠けていないstatic初期化
  private static final Foo foo = new Foo();
　これは本当に初期化するのか、foo staticクラスのフィールドの最低ひとつに
　さわりにいかないとJVMはこの初期化をサボる可能性あり。
■　オンデマンド初期化ホルダー
    CORBAっぽい。
■　volatileを正しく実装していないVMがあるらしい、使用禁止！！！。
    JCK Java Compatibility Kit のテストが通ればいい、
    dug Leeはvolatileはまだmemory model compatiblity test
    をクリアしていない。から使うな、といっている。

雑談ネタ
■　JavaOne皆さん１／３くらい行くみたいです、高橋さん初日Borlandブースだそうです。
■　来年くらいからはEAI( Enterprize Application Integraton)がホットになるはず。
■　次回課題図書、次までには決めましょう。

    次回は　項目49から
以上    根本和郎

[ 戻る ]