K.Maebashi's BBS 管理者削除

貴殿の「Java謎＋落とし穴」は私の愛読書で、もう、10年以上も手許に置き、 休日の午後など、思い出しては手に取って、ニヤニヤしている時間が好き です。もう少し余裕ができたら、「 プログラミング言語を作る」を読み込 んでみたいと思ってます（プログラミング工学の楽しい部分なのですが、 私にはチとハードルが高い）。 私は、Lattice C からの「C言語使い」です。K&Rにも随分お世話になりま した。現在、愛知県某社の某基幹システムのリニューアルで、これまで C言語で実装されていた UNIXサーバーの巨大システムを、Javaにコンバー トする仕事をしております。 仕事と言いましても、もはや定年までカウントダウンの身、第一線から引 き、「相談役」みたいな立場で食い繋がせて頂いております。 Javaプログラマとしての経験は浅いことを申し添えておきます。 昨日、若者から以下の様な相談をされました。 　　大量データ検証で、あるクラスのアウトプットが、List<データ型> 　　(ArrayList) で、100万件、消費メモリサイズが 10GB で、これでは 　　同時並行稼働すると、後続プロセスの JVMが起動することができなく 　　なる恐れがあります。 該当のサーバーは、今や当たり前の仮想モノで、JVM専用のヒープサイズ として約30GB割り当てられているのですが、これでは、多分2平行でも、 OutOfMemory となってしまうでしょう。何せ、解析ツールによると、 処理中に GC発生しまくりで、いわばメモリ確保とGCの追っかけっこ、 GCが追い付かない時の最大使用メモリが 20GBに達する、とのこと。 このクラスのコンバート元である、いわゆるC言語の関数では、いわゆる 構造体のリストで、その構造体のサイズは80バイト、100万件でも 80MB、 これにリスト形成に必要なオーバーヘッドを加えても、たかが知れてます。 このアウトプットの 10GB と 80MB の差という視点に絞ってサクッと考え ると、Java 側の <データ型> が、bean よりもさらに保安性、利便性？で ガチガチに固められた、某社標準の「フレームワーク」準拠のスーパーク ラスをスーパークラスに、このシステムオリジナルの利便性をプラスした もので、純粋なデータ部分のオーバーヘッドが酷いものと思われる。 これに対し、私は一言、「<データ型>を、せめて bean にしなさい。」と 伝えた。 これに対する、若者の回答が問題なのだ。 　　若者「Null Pointer Exceptionが怖くて、それはできません。」 　　私「…。」 「メモリ馬鹿ばか食い」はともかく、「プログラマーの資質（≒誇り）」 まで低下させる、嫌な言語だ、Java は。 　「プログラマーの資質（≒誇り）」も、C言語と Java とは違う所に ある様なんですね。