JRE」というのが用意されていることに気がついた。いうのが今回のテーマ。Solarisは無視)。JDKとJREはじめに、複雑怪奇なJavaパッケージについて少し解説しておく。「Javaをインストール」という場合には、開発キットであるJDKとランタイムであるJRE、どちらをインストールするかが問題になる。この日記を読んでいるような人ならばJava開発者であろうから、JDKを入れてしまえばほぼ間違いなく問題は解決する。JDKはJREを内包しているので、JDKをインストールすれば自動的にJREも入るからである。いうわけで開発者なら、何も考えずにJDKを入れてしまえば良い(動作検証のため複数バージョンのJRE混在とか、いろいろ問題は山積みだが、とりあえずその辺は置いておく)。JREという3つめのJavaが配布されるようになった(http://www.jpcert.or.jp/tips/2013/wr132201.html)。JREとは、サーバ向けのJREである。......とだけ書くとさっぱり説明になっていない気がするので、もう少し背景を説明すると。そのためTomcat環境などでJavaアプリケーションを動かしているLinuxサーバ管理者も、日々サーバにインストールしているJavaのアップデートをおこなわなければいけない。Javaの脆弱性のほとんどは、JavaアプレットなどWebブラウザのプラグインで動作する部分の脆弱性である。サーバサイドJavaでは当然このような脆弱性は全く関係ないのだが、何しろJavaのパッケージはJREならJRE、一つだけしかないので、政治的な理由や社内ルールなどで「脆弱性が出ているパッケージを使い続けるのか!?」と言われて渋々アップデート対応している人も多いだろう。この問題は、例えばLinuxならば「デスクトップLinux向けのJava」と、「サーバLinux向けのJava」が分けて提供されていれば解決することになる。サーバLinux向けのJavaには、脆弱性がしょっちゅう見つかるWebブラウザ向けのプラグインなどが入っていなければ嬉しいわけだ。JREの提供は、まさにこの用途である。JREのパッケージ(server-jre-7u51-linux-x64.tar.gz)を展開してみると、JREと言いつつ[jdk1.7.0_51]というディレクトリ名で展開される。JREのベースはJREではなく、JDKと考えた方が良い。JREは、Webブラウザ向けプラグイン絡みのライブラリがごっそり削除されている。JDKならば存在したjre/lib/plugin.jarファイルなどが同梱されていない。これで余計なセキュリティリスクを無くしているわけだ。基本的なファイルは揃っているため、今まで動いていたアプリはだいたい動くはずである。7.0.52を動作させてみたところ、私の試した範囲では何も問題は無かった。JREは、通常のJREでは同梱されていないjpsコマンドやjstatコマンドが、binディレクトリに入っている。JREでのbinディレクトリのファイルリストの差を書いておく。JREのbinディレクトリはJDKで揃っているものがだいたい入っている。JREだけでもTomcatを動かすことはできるのだけど、JREではjstatコマンドなどが用意されていないため、Tomcatのヒープメモリの状態を確認できずに困った......という経験をしたことのある人は多いだろう(む、私だけか?)。JREならば、これらのコマンドが入っているためLinuxサーバ上で安心して利用できる。ちなみにjpsコマンドとjstatコマンドは以下のような感じで使う。time(ms)>以下がTomcatのヒープメモリを確認する例。0.096ここで、S0やS1はSurvivor領域、EはEden領域である。JVMは時折このようなメルヘンチックな名前が付いているが、深みにはまると人として帰って来れなくなるので近づかない方が良い(偏見)。JREの内容がだいたい分かったので、これを実際にサーバにどうインストールして運用するか、ちょっと考えてみる。JREは以下のようなデメリットを持つため、これが問題になる環境では利用できないだろう。Solarisは無視してLinuxだけで考えます。JREだけはtar.gz形式のみで、RPMパッケージが提供されない。そのためパッケージ管理したい人には不向きである。Linux環境には適用できない。ちなみにSolaris版は32bit版も提供されている。JREはまだ登場したばかりなので、Oracleは「同梱ライブラリは今後精査していく」とアナウンスしている(https://blogs.oracle.com/security/entry/maintaining_the_security_worthiness_of)。あなたが必要とするライブラリがある日突然同梱されなくなる可能性がある。JREは、まだ積極的に使う必要は無いかな......というのが個人的な思い。JVMのサーバーVM最後にちょっと補足。Java仮想マシン)には、クライアントVMとサーバーVMという2つのモードがある。JRE」とは全くの無関係である。混乱を払拭するために、ここで敢えて説明しておく。クライアントVMとサーバーVMというのは、Java実行時のJava仮想マシンの動作モードである。これはパフォーマンスに影響があるだけで、やれることは基本的に同じである。ご想像の通り、サーバーVMの方が長時間稼働するサーバーアプリケーションの実行に適したチューニングとなっている。クライアントVMは起動の早さを優先している(らしい)。イメージとしては以下のようになる。起動の早さとメモリ消費の小ささを優先。マリオカートで言えばヨッシー。起動速度よりも、長時間稼働時のパフォーマンスを優先。マリオカートで言えばクッパ。これらのモードは、javaコマンド実行時(すなわちJava仮想マシン起動時)にOS環境によって自動的に決定される。お使いのマシンで、javaコマンドに-versionオプションを付ければ表示されるはずである。VM"と表示されている。VMが選択される(メモリの量、CPUの数、32bitか64bitか、あたりが判定基準だったはず)。この選択候補は、JRE内の[/jre/lib//jvm.cfg]ファイルに記載されている。以下は64bit版Linuxの該当ファイルである。ERRORこのように、-serverと-clientが用意されているのが分かる。VMが起動してしまうマシンでも、Java実行時に-serverオプションを付ければサーバーVMとして起動することができる。これはTomcat実行時によく使われるテクニックである。(Tomcat実行時のJAVA_OPTSに、-serverを明示的に付けておく)。蛇足だが、ここで出てくるHotSpotとは、Sun(じゃなかった、Oracleと言うべきか)のJVM高速化技術の名称である。OpenJDKでは、このHotSpotというのは出てこない。下図はOpenJDKの場合である。HotSpot」と出てきたら、それは全て読み飛ばして「Java」とだけ読んで理解してもあまり困らない。余談だけで長くなってしまったが、これで以下の出力の意味がうっすら分かってきたのでは無かろうか。mode)参考情報Javaの言語仕様およびVMのドキュメントについては、Oracleが無料でPDFを配布している(ただし英語)。Editionこれらは、以前にピアソン桐原から出版されていた「Java言語仕様」と「Java仮想マシン仕様」である。英語が読めると、こういう風に情報源が大きく広がるんだなぁ、という好例。Qiitaの19日目です。関する罪」の情報公開請求をしました月別アーカイブはてなブログをはじめよう!ozumaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。