[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfriends-ml 10703] More Java Pitfalls を読 む会第 1 回議 事録



高橋(徹)です。

"More Java Pitfalls"を読む会 第1回議事録

開催日時:2003年5月31日 10:00 〜 17:00
開催場所:目黒区中小企業センター第2集会室
参加者(敬称略):伊藤、高橋(智)、中村、宮本、秋元、村上、村山、
根本、金井、石黒、高橋(徹)

自己紹介:省略
書記:高橋(徹)
読み手:順番に輪読

今回は、英語の書籍を読む初の読書会となった。やり方は事前には決めていな
かったので、開始時に相談し、英語を朗読するのではなくその場で日本語に訳
しながら話すことにした。

■Introduction
What Is a Pitfall?を読む。Weak separation of concerns においてJAXRの例
が挙げられていた。JAXRは汎用的に作られている分APIが分かりにくいとの意
見が出た。また、separation of concernsはアスペクト指向で使用されている
言葉との補足あり。

What Is a Pitfall? を読み終わってから、Introduction章をこのまま読み進
めるか、最初のItem1へ移るか議論があり、Item1へ移ることに決定。

■Item1: When Runtime.exec() Won't
概要
・java.lang.Runtimeのexec()メソッド4種類
・java.lang.ProcessのexitValue()とwaitFor()
・waitFor()で永遠に戻ってこないプロセス。標準入出力、標準エラー出力を
取ろう

Windowsでは、拡張子が.htmlのファイルを直接指定すればブラウザが起動する
との話題が出た。しかし、これはコマンドプロンプトが解釈しているので、起
動する際はコマンドプロンプト経由でなければならないとの補足あり。

例では、exec()で引数に"javac"を指定していたが、Javaコンパイラを起動す
るのにjavacと名前をハードコーディングしない方法はないか?
(議事録担当者補足) JSR199 "Java Compiler API"が該当しそうです。J2SE
1.5で導入される予定の機能です。
http://www.jcp.org/en/jsr/detail?id=199

Gobblerは、「ごくごく」とか「ばくばく」の意味。

コマンドプロンプトは、同じWindowsでもOSによって違う。9x系(Meも含む)は、
command.comで、NT系はcmd.exe。

例題コードでは、OSの名前を調べて処理を振り分けているが、XPやMeはどうな
るのだろうか?

p.10の例題コードで、execの引数を配列としているのは、cmd.exeに実行させ
たいパラメータを渡すときに、スペースが含まれている文字列をJavaのパーサ
(StringTokenizer)が切り分けてしまうのを防ぐため。

例題のソースコードは変なインデントを採用している。

例題のソースコードは、waitForを呼んでからjoinを呼んでいるが、joinを
呼んでからwaitForした方がよいのではないか?

PrintWriterは例外を投げないので、このような使用はいかがなものか?例え
ばファイル書き出しが失敗してもそのまま処理が続いてしまう。
WriterならOK。PrintWriterは、System.out.printlnのようにいちいち
try-catchするのが大変なときに使っている。

例題のソースコードでは、ストリームをcloseしていない。

■Item2: NIO Performance and Pitfalls
概要
・大きなサイズのファイルコピーは、NIOを使うと速い。
・エンディアン変換が必要なときに、NIOを使うとよい。
・UDPなどの受信で多重化するときは、NIOを使うとよい。

FileChannelのtransferToは何故速いのか?
小さいサイズのファイルだと少し遅くなるとはどういうことか?
以上宿題としたが、JavaDocをインストールしているPCを持ってきた方が調べ
た結果解答がその場で得られた。
ファイルシステムのキャッシュからJavaVM側にコピーせずに直接データを転送
できるため速い。このバッファはJavaVMのヒープには取られない。ただし、バ
ッ
ファの作成コストが大きいため、小さいファイルの時は遅くなることがある。

エンディアンを指定するメソッド名がorderとあるが、setOrderの方がよいの
では?

■Item3: I Prefer Not to Use Properties
概要
・プロパティは階層化されていないが、プリファレンスは階層化されている。
・プリファレンスは保存位置の指定が標準化されている。

プリファレンスの設定内容のポータビリティは? XMLファイル化できるか?
→ インポート/エクスポート機能がある。

Windowsの場合、プリファレンスの保存にはレジストリが使われるが、これは
いかがなものか?
複数のプロパティをまとめる(?)とか、同じユーザでも設定を切り変えたいと
きに融通がきかない。
プログラマ的には細かく制御できた方が便利だが、一般ユーザの場合にコマン
ドラインオプションで指定させたりというのは現実的ではない。

Linuxでは、プリファレンスはどこに保存されるのだろうか?
ユーザの場合はホームディレクトリと思われる。システムは?

■Item4: When Information Hiding Hides Too Much
概要
・フレームワークの内部で扱うAPIで例外が発行された場合、その例外を含め
た例外をフレームワーク使用者へ投げるようにすべき。JDK1.4なら例外連鎖が
利用できる。

p.40 creational design patternとあるが、これはGoFの生成に関するデザイ
ンパターンのことか?

例題のソースコードでは、LDAPExceptionを用いているが、内容はLDAPとは全
然関連がない。例がおおげさすぎる。
前の節でJNDIがちらっと出てきたからその続きのつもりかもしれない。

JDK1.4以前でも、自分で作る例外には原因(cause)を保持するようにしていた。

■Item5: Avoiding Granularity Pitfalls in java.util.logging
概要
・ログ出力に指定するレベル

時間切れでこのItemは途中まで(p.48)で終了。

--
TAKAHASHI Toru
torutk@xxxxxxxxxxxx