変奏現実

1. コンパイラが超低速である。
   • C言語のヘッダーみたいなインタフェースと実コードの分離の概念が無い。
     • ソース毎にカレントパスとクラスパスの全コードを検索。
       • コードの物量が多いと処理時間は半端ではない。
   • import宣言の無いJavaソースは皆無、クラスパス検索の頻度が非常に高い。
     • HDDの乗り換えると回転数の差を実感できる。
       • 故にエコなHDDはJavaに向いていない。
   • JITコンパイラは実装されているがJavaコードのコンパイルとは関係ない。
     • でも、一度目と二度目の実行時間の差がハッキリ判るくらい性能は高い。
       • だが、デバッグするのは一度目の実行だ。
2. JITコンパイラが吐き出すマシン語コードは・・・
   • マシン語コードは特定のフォルダーにキャッシュされる。
     • キャッシュ容量は意外と小さく制限されている。
       • 容量を拡張するオプションは見当たらない。
   • 大きなJavaで作った巨大システムは大抵キャッシュ容量より大きい。
     • 実行中にマシン語コードを作っては捨ての繰り返しになると処理時間と云うか処理待ち時間がひどく長くなる。
       • キャッシュに入る程度のサイズに分割しプロセスを分離するのは必然。
         • たくさんのプロセスを常駐しないと使えないものになる。
           • ハードウェア・スペックが無駄に高くなる。
           • 負荷が上がればどのみち耐えられない。
   • 某ウイルス監視ソフトウェアの大好物である。
3. 普通どのクラスライブラリィも資料といえば・・・
   • JavaDocと意味不明な短いサンプルのみ。
     • 使ってみないと、使えるモノのかどうか判断できない。
       • 致命的な問題が発生した時は、大抵すでに手遅れである。
4. オブジェクト管理はGCに大きく依存している。
   • GCの処理時間はオブジェクト数の２乗に比例する。
     • ヒープを食い尽くすとGCが現実的な時間内に終了しない。
       • システムの方は停止した様に見える。
         • 大容量のヒープメモリを設定すれば大事故になる。
   • どんなにハードウェアのスペックを上げても扱えるデータはM単位が上限。
     • だからJavaで画像や動画を処理させるのは本来かなりリスクが高い。
     • だから不特定多数のユーザを相手にするWebもリスクが高い。

と云う感じのJavaですが小さいモノ作りなら許容範囲内ですよね。
でも、数百人のJavaプログラマーが作り上げたコードを一つのサーバーで動かす用途には全く向いていません。
と同時、色々な機能を繋げて使いたいと云う考えにも向いていません。
しかし、簡単に思えるモノはお金にならないのが世間一般のルールなので、
金が絡むから、何でも巨大化してしまいます。
例えJavaを使う場合でも変わるわけがないんですよね。（合掌