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 とは違う所に ある様なんですね。

はじめまして。すっかり閑古鳥な掲示板ですが、投稿ありがとうございます。 >貴殿の「Java謎＋落とし穴」は私の愛読書で、もう、10年以上も手許に置き、 >休日の午後など、思い出しては手に取って、ニヤニヤしている時間が好き >です。もう少し余裕ができたら、「 プログラミング言語を作る」を読み込 >んでみたいと思ってます（プログラミング工学の楽しい部分なのですが、 >私にはチとハードルが高い）。 ありがとうございます。「Java謎＋落とし穴」は、さすがに今となっては 内容が古いのですが、Tiger以前の本としては良く書けた本であったと 自分でも自賛しております。 >このクラスのコンバート元である、いわゆるC言語の関数では、いわゆる >構造体のリストで、その構造体のサイズは80バイト、100万件でも 80MB、 >これにリスト形成に必要なオーバーヘッドを加えても、たかが知れてます。 100倍以上となると単に言語の違いとするには差が大きすぎますし、 Cだと1回のmalloc()で済むものがJavaだといくつものオブジェクトに なってしまうというのもありがちですが(たとえばCなら構造体に intの配列を埋め込んでいたところ、JavaだとArrayList<Integer>を 使ったりすると、あっさり100倍くらいにはなりそうな気がします)、 『某社標準の「フレームワーク」』が問題なのでしょうか。 ものを見ていないので何も言えませんけれども。 >これに対する、若者の回答が問題なのだ。 >　　若者「Null Pointer Exceptionが怖くて、それはできません。」 NullPointerExceptionはバグがあるから起きるので、それ自体を避けたからといって 問題の解決にはなりませんよね(『某社標準の「フレームワーク」』を使うと、 どうNullPointerExceptionを避けられるのかはわかりませんが)。 >「メモリ馬鹿ばか食い」はともかく、「プログラマーの資質（≒誇り）」 >まで低下させる、嫌な言語だ、Java は。 とはいえ、それをJavaという言語のせいにするのもちょっと(Javaに対して)酷なような気が……

前橋様 お返事有難うございます。まさかお返事を頂けると思っておりませんでしたので、 ホントに嬉しい限りです。実にショボイ当方の職場のドキュメンタリーは二の次、 先ずは、熱心な貴殿の１ファンの応援メールと受けって頂ければ幸いです。 某社 F/W のレコードクラスは、Null値がセットされたメンバの値を get すると、 長さ 0 の文字列を返す様にカスタマイズされています。その経緯は、過去の開発 プロジェクトにおいて、ヌルポが氾濫していたのに対し、これを一気に黙らせる為 の策が、そのまま生き残ったもの、と聞き及んでいます。 つまり嫌なのは Javaの言語使用なのではなく、このアホダラ F/W で育ったプログ ラマーの資質の低下です。 穿った見方と思いますが、アセンブラや C言語で鍛えられたプログラマーは、設計、 仕様、要件をやらしても、モレや矛盾といったバグを仕込むことが少ないと思いま す。 「ユーザーをバカにするシステムは、良いシステム」という、妙な格言紛いよろし く、「プログラマーをバカにするプログラミング言語は、良い言語」では困りモノ です。考えなくて良くなる分、その代わりに、高品質、短納期、斬新なアイデアを O/P して欲しいものです。 「レコードクラスの100倍肥大化」は、多分、若者の早合点と思っており、若者には 妙な言い訳をすることなく、真因を見極めるアプローチを怠って欲しくないと思い ます（デバッグ鍛錬）。 「Java謎＋落とし穴」から、Tiger となり、Java も随分進化したものと思いますが、 貴殿がもし、同書の改定新版を上梓したとき、「謎＋落とし穴」は果たして減って いるのか増えているのかが、気になるところでございます、Hi。

>某社 F/W のレコードクラスは、Null値がセットされたメンバの値を get すると、 >長さ 0 の文字列を返す様にカスタマイズされています。その経緯は、過去の開発 >プロジェクトにおいて、ヌルポが氾濫していたのに対し、これを一気に黙らせる為 >の策が、そのまま生き残ったもの、と聞き及んでいます。 これは…… NullPointerExceptionは避けられるかもしれませんが、 アプリの要件として絶対に値を入れなければいけないところを空文字に してしまったら、バグの発覚が遅れるだけですよね。 (この手のことは、拙著「センス・オブ・プログラミング!」で 「バグのあるプログラムには生きる価値はない」として書かせていただきました) 要件として、デフォルト空文字列でよいところは、コンストラクタ等で 空文字列で初期化するのは正しいと思いますが。 >「レコードクラスの100倍肥大化」は、多分、若者の早合点と思っており、若者には >妙な言い訳をすることなく、真因を見極めるアプローチを怠って欲しくないと思い >ます（デバッグ鍛錬）。 早合点なら、それでよいのですけれど。実際にメモリをバカ食いしている以上、 どこかに何かの原因があるのかとは思いますが。 >「Java謎＋落とし穴」から、Tiger となり、Java も随分進化したものと思いますが、 >貴殿がもし、同書の改定新版を上梓したとき、「謎＋落とし穴」は果たして減って >いるのか増えているのかが、気になるところでございます、Hi。 JavaのGenericsはあれはあれで落とし穴が多いのですが、本1冊書くのは それはそれは大変なので、当面おとなしくしていたいと思います。Hi。