Link:

---

>はじめまして。

はじめまして。読んでいただきありがとうございます。

>p.114 List2-6 12行目
>コメントとの対応を考えると、%edではなく%edxではないでしょうか。

そうですね。オリジナルのソースを見ると%edxになっているので、
編集段階で(矢印を入れたときに?)xが消えてしまったようです。
確認不足でした。申し訳ありません。

>p.226 10の後の英語的表現
>英文の2行目最後のfucntion(int)の後に閉じ括弧)がありますが、
>不要ではないでしょうか。

こちらもそのとおりです。申し訳ありません。

ご指摘ありがとうございました。後ほど正誤表に入れさせていただきます。

Link:

---

重ねて質問させていただきます。
C言語ポインタ完全制覇 P.243-246 の、read_line()関数を、引数にstdinを渡して呼び出す部分について聞かせていただきたいです。

例えば標準入力から、
abcd[Enter]
ef[EOF]
というように入力すると、read_line()関数は、P.244 List4-6 の61-75行目の処理で、
まず"abcd\0"を返し、次にline_bufferが"ef"になったところでchがEOFとなるので61行目のwhileを抜けて69行目に進み、結果"ef\0"を返します。

この時点でまだNULLを返さないので、main()関数のwhileは次のループに入り、再びread_line()関数にstdinを渡して呼び出すこととなりますが、この時に61行目のgetc(fp)で取り出される値は何なのでしょうか。

実験してみると、どうもこの段階でEOF(だけ)を取り出していて72行目に進み、read_line()関数がNULLを返しているようなのですが、標準入力においてキーアクションのEOFの後に続けて入力を行うことが可能ならば、getc(fp)でその入力値を受け取ってしまうということはないのでしょうか。

それとも標準入力において一度EOFが入力されたら、以降標準入力から取り出される値はEOFとなることが決まっているのでしょうか。

Link:

---

はじめまして。
C言語ポインタ完全制覇(初版　第一刷)の内容についていくつか確認させていただきたいです。

C言語勉強中、アセンブリ言語については全く知らない身なので、見当外れな質問でしたら申し訳ないです。

p.114 List2-6 12行目
コメントとの対応を考えると、%edではなく%edxではないでしょうか。

p.226 10の後の英語的表現
英文の2行目最後のfucntion(int)の後に閉じ括弧)がありますが、不要ではないでしょうか。

Link:

---

ご連絡ありがとうございます。

正誤表を確認しました。
ご対応、ありがとうございました。

Link:

---

はじめまして。遅くなりましてすみません。

>330ページにある、
>void (*draw_shape_func_table)(Shape *shape)[]
>というのは、誤植ではないでしょうか？
>正しくは、
>void (*draw_shape_func_table[])(Shape *shape)
>だと思います。

確認しました。これはこの本のテーマにもろに重なっているという点で
かなりまずいミスでした。申し訳ありません。
「わからない人は3章を読み返しましょう」って書いてあるのが
我ながら余計に痛いです。

正誤表に載せておきます。ご指摘ありがとうございました。

Link:

---

前橋和弥様

改訂版のC言語ポインタ完全制覇を読んだものです。
非常にためになる本で、常日頃参考にさせて頂いております。
今回は、この本に誤植らしきものがあるので、ご連絡致しました。

330ページにある、
void (*draw_shape_func_table)(Shape *shape)[]
というのは、誤植ではないでしょうか？
正しくは、
void (*draw_shape_func_table[])(Shape *shape)
だと思います。
前者だとコンパイルが通りませんでした。

以上、確認をお願い致します。

Link:

---

>ぱさんの本で自分がポインターの何が解っていないか初めて解り
>大変良い物だとありがたい限りです

はじめまして。読んでいただきありがとうございます。

>ところで次のような物を見つけたのでご存じなければつまみにでもどうぞ
>https://cdecl.org/

紹介ありがとうございます。初めて知りました。
ポインタ完全制覇でも取り上げた、K&Rに載っているdclのWeb版ですね。
Webで簡単に解析できるのは便利なので、あとはひっくり返して日本語に
してくれれば…… と思うのですが、自分で作れと言われそう。
時間があれば、作ってみたい気はするのですが。

Link:

---

こんばんは

ぱさんの本で自分がポインターの何が解っていないか初めて解り
大変良い物だとありがたい限りです

ところで次のような物を見つけたのでご存じなければつまみにでもどうぞ
https://cdecl.org/

Link:

---

>レスが付かないまま１週間以上たってしまったため、自己レスします。 

すみません、最近どたばたしておりまして、ちょっと気力がたまりませんでした。

>で、パケット解析をするとすぐわかりますが、ブラウザから
[ http://localhost:8001/日本語 ] ;でアクセスすると、
>サーバからレスポンスコード301が返ってきており、
>そこで指定されている移動先URLが文字化けしています。 

なるほど…… これはさすがに気付いてしかるべきでしたね。
パケットキャプチャやFiddlerどころか、F12開発者ツールでわかるレベルの話です。

言い訳しますと、

>SenderThread.javaの24行目に、以下のようにSystem.out.println()を挟んで確認しました。

…という確認をしていたのにリクエストは1回ずつしか来なかったので、
リダイレクトは想定しませんでした。最初の1回はちゃんと飛んでたはずですが
(過去投稿を見るとIEではそうだったとの記載もある)、今F12を入れて見てみると、
2回目以後はキャッシュされてますね。
「F12開発者ツール」とか、「変な動きがあればキャッシュを消せ」あたりは
Webアプリ開発の基本ですが、どうもぼけてたようです。

Link:

---

削除パスワードを設定していなかったため修正も削除もできないため返信します。
前回の発言、一部間違っていました。ダウンロードしたのは再現テストの前、一番最初です。

Link:

---

レスが付かないまま１週間以上たってしまったため、自己レスします。 
> さすがにどっかで化けているとしたらブラウザだと思うのですが 
思い込みの罠にはまっています。というか傍から見ると自分でフラグ立てていますよ。 

fidderをプロキシとしてブラウザとサーバの間に挟むと若干動きが変わりますが、パケット解析には問題ないです。 
で、パケット解析をするとすぐわかりますが、ブラウザから[ http://localhost:8001/日本語 ]でアクセスすると、サーバからレスポンスコード301が返ってきており、そこで指定されている移動先URLが文字化けしています。 ;

で、（サポートページから勝手にソースをダウンロードして）問題箇所を見ると、ServerThread.javaのpathの扱いが不注意なところがありました。 
まず、25行目で、urldecodeプラスアルファ的なことをしていて、url文字列からPCで扱う文字列にしています。 
その後、54行目で、移動先ページの組み立てで、PCで扱う文字列となっているpathを(url文字列形式にせずに)そのまま使っています。 
urlデコードしてもしなくても変わらない文字列であれば問題が起きなかったのですが、今回はそのケースではないためエラーが見つかっちゃったんだと思います。 
仮に56行目 [ + path + "/"; ]の部分を[ + "/%E6%97%A5%E6%9C%AC%E8%AA%9E/"; ]に書き換えれば意図通りにいっているように見えるんじゃないかな？ 

Link:

---

なるほど。。。
確かに自分で実装したTcpClientなら余計な補正は働きませんね。
動作確認できました。ありがとうございました。

Link:

---

最初からガッツリ調べなくても最初はfiddlerでいいんじゃない？appgoatの学習でも使っているツールだし。。。

Link:

---

ごぶさたしてます。

>なので、問題となった%E5,%9Eは、日本語をUnicode符合位置で求めた場合の
>下位1バイト分に相当します。

あ、気付いていませんでしたが確かにそうですね。
だとしても、なぜ「日本語」の場合だけそうなるのは謎ですが……

本件、Modoki/0.2はただソケットでデータを受け取るだけなので、
さすがにどっかで化けているとしたらブラウザだと思うのですが、
パケットフィルタリングもちょっと考えてみます。(今でもWiresharkで
よかったんだっけ…?)

Link:

---

>過去の例にあったような「http://localhost:8001/../conf/httpd.conf」
>をブラウザで入力してデバッグすると、NoSuchFileExceptionが先に発生するような
>動きをしてしまいました。

ブラウザは、こんなあからさまにディレクトリトラバーサルを起こしそうなURLを
素直にサーバに送らなければいけない義理もないでしょうから、

>「GET /conf/httpd.conf HTTP/1.1」となっていましたので、

というように(勝手に)変換しているのでしょう。

ただ、攻撃者はブラウザを使うとは限らないわけで、TcpClient.javaを使って
client_send.txtに

GET /../conf/httpd.conf HTTP/1.1

と書くと、

if (!realPath.startsWith(DOCUMENT_ROOT)) {

側の処理に流れ込むことが確認できます。

Link:

---

本を持っていないため、推測となってしまいますし、外しているかもしれませんが。。。
日本語のそれぞれの文字のUnicode符合位置は、[日]=U+65E5、[本]=U+672C、[語]=U+8A9Eです。
また、「,」は、Unicode符合位置がU+002Cです。
なので、問題となった%E5,%9Eは、日本語をUnicode符合位置で求めた場合の下位1バイト分に相当します。
この辺を手がかりに、パケットキャプチャすればどのタイミングまでは文字コードが意図通りとなっているかがのあたりがつくかもです。

Link:

---

こんばんは。

早々にご確認・ご回答頂きまして、まことにありがとうございます。
当方でも様々な文字で確認してみましたが、やはり上手くいくときといかないときがあり、よくわからない結果となってしまいました。
ブラウザ等の仕様に起因するところもあるかと思うので厳密には分からないかとは思いますが、もともとの目的である動き・仕様は理解できたので先に進もうかと思います。

ちなみに、また別の質問となってしまい恐縮ですが、
Modoki/0.2で、ディレクトリトラバーサル攻撃を検知 → 404.htmlをリターンする、
即ち (!realPath.startsWith(DOCUMENT_ROOT)) を true にするには、
どのようなGETリクエストを飛ばすと実現できるものでしょうか？

過去の例にあったような「http://localhost:8001/../conf/httpd.conf」
をブラウザで入力してデバッグすると、NoSuchFileExceptionが先に発生するような動きをしてしまいました。

TcpServerを動かして、ブラウザに「http://localhost:8001/../conf/httpd.conf」
を入力して、GETリクエストを取得してみると、
「GET /conf/httpd.conf HTTP/1.1」となっていましたので、
サーバがGETリクエストを受け取った時には、pathが/conf/httpd.confとなっているようです。
そうすると、realPathは「C:\Apache24\htdocs\conf\httpd.conf」になるので、
確かに、NoSuchFileExceptionが発生することが自然な動きのようにも思えます。

以上、よろしくお願いいたします。

Link:

---

はじめまして。ご質問いただきありがとうございます。

>入力URL　結果
>/test    OK（test配下のindex.htmlが表示）
>/test/　 OK（test配下のindex.htmlが表示）
>/日本語  NG（404.htmlも表示されずブラウザのエラー画面が表示）
>/日本語/ OK（日本語配下のindex.htmlが表示）

私も試してみましたが、正直、わけがわからない結果となっています。

Firefox, Edgeでは、

/日本語

の場合だけ、リクエストラインが以下のようになっています。

GET /%E5,%9E/ HTTP/1.1

これをデコードしても該当のフォルダは存在しないので、私が試した範囲では、
404が返りました。
IEでは、1回だけ

GET /%E6%97%A5%E6%9C%AC%E8%AA%9E HTTP/1.1

つまり正しくエンコードされた形でリクエストが投げられましたが、
以後何度試しても、そもそもリクエストが投げられず、ブラウザ側で
「このページを表示できません　
　Web アドレス http://localhost:8001  ;が正しいか確かめてください」
のエラーになっています。

奇妙なのは、Edge, Firefox, IEのどれにおいても、

http://localhost:8001/日本語/
http://localhost:8001/日本語.html
http://localhost:8001/あいうえお
http://localhost:8001/中国語

等はうまくいくのに、

http://localhost:8001/日本語

の場合だけ、

GET /%E5,%9E/ HTTP/1.1

になったり、リクエストが投げられなかったりしていることです。

SenderThread.javaの24行目に、以下のようにSystem.out.println()を挟んで確認しました。

  while ((line = Util.readLine(input)) != null) {
      if (line.equals(""))
          break;
      System.out.println("line.." + line);

Link:

---

はじめまして。
「Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門」にて実装したModoki/0.2の挙動について質問となります。

Modoki/0.2では、'/'なしでディレクトリを指定するとリダイレクトさせる仕様となっております。
そのため、「C:\Apache24\htdocs\」の配下にテストディレクトリ「test」と「日本語」を作成し、それぞれのディレクトリ配下にindex.htmlを配置して動かしてみました。

実行結果は以下の通りです。（入力URLはhttp://〜8001までは省略）

入力URL　結果
/test    OK（test配下のindex.htmlが表示）
/test/　 OK（test配下のindex.htmlが表示）
/日本語  NG（404.htmlも表示されずブラウザのエラー画面が表示）
/日本語/ OK（日本語配下のindex.htmlが表示）

ブラウザはIEでもFireFoxでも同じ結果でした。
デバッグモードで戻り値を確認してみましたが、MyURLDecoderは「/日本語」を返してくれていますし、realPathの取得時もNoSuchFileExceptionは発生していません。
このような差異が発生してしまう要因として考えられることはどのようなものでしょうか？

Link:

---

>webサーバを作ってみようページの以下リンクが切れております。

ありえないほど遅くなりましたが、ご指摘ありがとうございます。

とはいえよそのページなので消えるときは消えますし、それについて私にできることは
特にないよなー、と思ったのですが、Wayback Machineの存在を思い出したので
そちらに張りなおしておきました。

Link:

---

webサーバを作ってみようページの以下リンクが切れております。

http://ascii.asciimw.jp/books/support/4-7561-1663-9/supplement/0001/shttpd

Link:

---

>p.84のリスト3-3で、POSTのHTTPリクエストのサンプルを掲載していますが、
>ここでcheck_nameという同一のパラメタが複数回登場しています。
>つまり、チェックボックスを複数選択すると、この状況が発生します。
>p.85の脚注にも書いたとおり、この仕様は使いにくいとは私も思うのですが。
>
>
テスト掲示板だけでなく、前の入力フォームにも対応できるよう書かれていたのですね。
サーブレットコンテナを作っているのだから、こういう場合も想定しなければならないのに、
どうも頭が固かったみたいです。

お答えいただき、ありがとうございました。
また何かありましたら、よろしくお願いいたします。

Link:

---

>リスト3-17の21行目でif(paramterMap.containsKey(keyValue[0]))が
>trueになるケースはどんな場合でしょうか？本文P119の中頃に、『同一のパラメタが
>複数存在し得る』とあるのですが、このパラメタとはtittle, handle, messageのことですよね。
>１回のリクエストでこれらが複数になる場合というのがどうもよくわかりません。

p.84のリスト3-3で、POSTのHTTPリクエストのサンプルを掲載していますが、
ここでcheck_nameという同一のパラメタが複数回登場しています。
つまり、チェックボックスを複数選択すると、この状況が発生します。
p.85の脚注にも書いたとおり、この仕様は使いにくいとは私も思うのですが。

Link:

---

ご回答いただき、ありがとうございます。

>(試していませんが)param.split("=", -1) とすればよいかと思います。
>
試してみたところ、これでうまくいきました。

投稿内容の取得については、教えていただいた流れを追っていき、やっとわかりました。

stringToMapメソッドについて、まだ理解できていない点があるのですが、
リスト3-17の21行目でif(paramterMap.containsKey(keyValue[0]))が
trueになるケースはどんな場合でしょうか？本文P119の中頃に、『同一のパラメタが
複数存在し得る』とあるのですが、このパラメタとはtittle, handle, messageのことですよね。
１回のリクエストでこれらが複数になる場合というのがどうもよくわかりません。

教えていただければ幸いです。

Link:

---

はじめまして。

>Henacat起動まではうまくできたのですが、掲示板のタイトル・ハンドル名
>・メッセージの内のどこかが
>未入力のままで送信を押すと、リスト3-17のServletServiceの28行目で
>java.lang.ArrayIndexOutOfBoundsExceptionが発生します。
>keyValue[0]に対するkeyValue[1]がない、ということだと思うんですが、
>これはどこかコードを写し間違えているでしょうか？

このケースでは、ServletServiceの20行目の param.split("=") のところで、
split()メソッドの仕様上、「a=」という文字列をparam.split("=")のように
split()すると、
・戻り値の配列の要素数は2で、[0]には「a」が、[1]には空文字が入る
のではなく、
・戻り値の配列の要素数は1で、[0]にだけ「a」が入る
という仕様になっているためですね。
https://docs.oracle.com/javase/jp/6/api/java/lang/String.html#split(java.lang.String)

(試していませんが)param.split("=", -1) とすればよいかと思います。

Henacatはあくまでサンプル実装なので、こういうエラーケース的なものの
対処が甘いのはご容赦ください、と言いたいところですが、これはちょっと
実用上問題がありすぎるので、後ほど正誤表に上げさせていただきます。
ご指摘ありがとうございました。

>あと、このstringToMapメソッド内のparameterMapに過去の投稿内容も
>保持しているという認識で合っているでしょうか？
>しかし毎回メソッドが呼ばれるたびにnewしていては過去の内容は
>保持できませんよね？

parameterMapは毎回メソッドが呼ばれるたびにnewしていて、
1回のリクエストごとに使い捨てです。
リスト3-17 ServletService.javaの76行目で、

info.servlet.service(req, resp);

としてサーブレットのservice()メソッドを呼んでいますが、
この呼び出しが、リスト3-26のHttpServlet.javaの13行目のservice()メソッドを
呼び出すことになり、この中で、メソッドがPOSTの場合は(サブクラスの)doPost()
メソッドを呼んでいますから(19行目)、これはつまりリスト3-6のPostBBS.javaの
doPost()メソッドを呼び出しています。
ここで、新たにMessageクラスのインスタンスをnewして、staticフィールドの
messageListにメッセージをつないでいます。

Link:

---

Henacat起動まではうまくできたのですが、掲示板のタイトル・ハンドル名・メッセージの内のどこかが
未入力のままで送信を押すと、リスト3-17のServletServiceの28行目でjava.lang.ArrayIndexOutOfBoundsExceptionが発生します。
keyValue[0]に対するkeyValue[1]がない、ということだと思うんですが、これはどこかコードを写し間違えているでしょうか？

あと、このstringToMapメソッド内のparameterMapに過去の投稿内容も保持しているという認識で
合っているでしょうか？しかし毎回メソッドが呼ばれるたびにnewしていては過去の内容は保持できませんよね？

基本的なところかもしれませんが、どなたかわかる方、教えていただけますでしょうか。

Link:

---

>某社 F/W のレコードクラスは、Null値がセットされたメンバの値を get すると、
>長さ 0 の文字列を返す様にカスタマイズされています。その経緯は、過去の開発
>プロジェクトにおいて、ヌルポが氾濫していたのに対し、これを一気に黙らせる為
>の策が、そのまま生き残ったもの、と聞き及んでいます。

これは…… NullPointerExceptionは避けられるかもしれませんが、
アプリの要件として絶対に値を入れなければいけないところを空文字に
してしまったら、バグの発覚が遅れるだけですよね。
(この手のことは、拙著「センス・オブ・プログラミング!」で
「バグのあるプログラムには生きる価値はない」として書かせていただきました)
要件として、デフォルト空文字列でよいところは、コンストラクタ等で
空文字列で初期化するのは正しいと思いますが。

>「レコードクラスの100倍肥大化」は、多分、若者の早合点と思っており、若者には
>妙な言い訳をすることなく、真因を見極めるアプローチを怠って欲しくないと思い
>ます（デバッグ鍛錬）。

早合点なら、それでよいのですけれど。実際にメモリをバカ食いしている以上、
どこかに何かの原因があるのかとは思いますが。

>「Java謎＋落とし穴」から、Tiger となり、Java も随分進化したものと思いますが、
>貴殿がもし、同書の改定新版を上梓したとき、「謎＋落とし穴」は果たして減って
>いるのか増えているのかが、気になるところでございます、Hi。

JavaのGenericsはあれはあれで落とし穴が多いのですが、本1冊書くのは
それはそれは大変なので、当面おとなしくしていたいと思います。Hi。

Link:

---

前橋様

お返事有難うございます。まさかお返事を頂けると思っておりませんでしたので、
ホントに嬉しい限りです。実にショボイ当方の職場のドキュメンタリーは二の次、
先ずは、熱心な貴殿の１ファンの応援メールと受けって頂ければ幸いです。

某社 F/W のレコードクラスは、Null値がセットされたメンバの値を get すると、
長さ 0 の文字列を返す様にカスタマイズされています。その経緯は、過去の開発
プロジェクトにおいて、ヌルポが氾濫していたのに対し、これを一気に黙らせる為
の策が、そのまま生き残ったもの、と聞き及んでいます。

つまり嫌なのは Javaの言語使用なのではなく、このアホダラ F/W で育ったプログ
ラマーの資質の低下です。

穿った見方と思いますが、アセンブラや C言語で鍛えられたプログラマーは、設計、
仕様、要件をやらしても、モレや矛盾といったバグを仕込むことが少ないと思いま
す。

「ユーザーをバカにするシステムは、良いシステム」という、妙な格言紛いよろし
く、「プログラマーをバカにするプログラミング言語は、良い言語」では困りモノ
です。考えなくて良くなる分、その代わりに、高品質、短納期、斬新なアイデアを
O/P して欲しいものです。

「レコードクラスの100倍肥大化」は、多分、若者の早合点と思っており、若者には
妙な言い訳をすることなく、真因を見極めるアプローチを怠って欲しくないと思い
ます（デバッグ鍛錬）。

「Java謎＋落とし穴」から、Tiger となり、Java も随分進化したものと思いますが、
貴殿がもし、同書の改定新版を上梓したとき、「謎＋落とし穴」は果たして減って
いるのか増えているのかが、気になるところでございます、Hi。

Link:

---

はじめまして。すっかり閑古鳥な掲示板ですが、投稿ありがとうございます。

>貴殿の「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に対して)酷なような気が……

Link:

---

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