JAVAってどうよ？

JAVA 読書

実はいろんな本を掛け持ちして読んでいるから進まない、という話。こっちは会社に置いてあるJAVAWORLDから。昼休みと残業前のわずかな時間に必死こいて読んでます。別に業務中に読んでも良いのだろうけど、文字通り業務で手一杯でムリぽ。業務中に本読める人とかうらやましいなぁ…と何故かひねくれつつ、11月号「JAVAの常識・非常識」という特集のメモ。走り書き。

Q.JAVAはWORA(Write Once，Run Anywhere)であるのか？
A.実際にはそうとも言えない

  • プラットフォームで動作が違う

→ネイティブアプリとの絡み、文字・改行コードに注意が必要。ただ、全般的には大きな問題はないと言える。

  • JAVAのバージョンによる仕様の違い

→上位バージョンの標準ライブラリは下からは使えない（当然）。下位互換APIを使えば解決？
→それだとそもそも上位の利便性がダメぽ
→バイトコードも然り、上位の機能を利用→下位で使えね（利便性と互換性がトレードオフ）。

  • JVMにおける動作の違い

→基本的にはSUNの仕様（本家）に乗っ取っていればVM非依存という話。



⇒これらのことからWORAは実用レベルでは達成されている（と言える？）



Q.JAVAは遅い？
A.クライアントサイドではその可能性もある

→JAVAは厳密なインタプリタ方式ではない。ある程度マシンコードに変換→JIT(Just-In-Time)コンパイル（これはここでも既出）。この場合も全てをJITコンパイルするのではなく、プロファイリングによって実行頻度の高い部分を特定（HotSpot技術）ｶｺｲｲ。 　
→これによりコンパイラ型ともかなり差を縮めているが、クライアントサイドではその場限りだったりしてHotSpotの恩恵が受けづらい→遅い

  • 起動時間の問題？

→サーバー側では無問題、しかしクライアント側では当然問題。
・１つのJVMで複数アプリを実行？
・OS起動時にJVMを実行？
などが検討されている、らしい（未解決）

  • メモリ使用量の問題？

→JAVAアプリがメモリを食うのは事実。だからサーバーはメモリたっぷりで良いけど、クライアントはヘタレな場合がどうしてもある→JAVA遅い、となる

  • GCの問題？

→GCの与える影響は現在最小限にするための仕組みが導入されている（これはまた今度）。但し、スレッドの停止時間ははっきりしない場合があるため、リアルタイム・システムなどでは要検討。


⇒以上、サーバ側なら気にならないけど、クライアント側だときついかもね、という話

以上、殴り書きでレイアウトもクソもなくてすいません。かなりオレバイアスもかかってると思うので、え？ええ！？ってとことかあったらこっそり突っ込んでください。つーか勝手に本の内容書いたりしたら怒られるんかな？という不安もあって、やや○○な内容になっておりますので注意が必要です。