Javaはまだまだこれからだ！

Java SE 7におけるプラットフォームの強化とは

皆さんこんにちは。本連載を担当させていただきますチェンジビジョンの近藤と申します。

世間ではJavaはすでに成熟期に入ったというような位置づけで語られることが増えてきているようです。本連載をお読みの方はどうお感じでしょうか。個人的な見解ですが、筆者はそうは思えません。

Javaには大きく分けて2つの側面があります。1つはプログラミング言語という側面です。静的なクラス構造を持ち、実行するためにはコンパイルが必要で、実行する前にプログラムの文法的な異常やクラス間のインターフェースの食い違いを発見します。

しかし、Rubyなどコンパイルが不要なスクリプト言語では対話型のシェル（実行環境）が整えられるようになりました。シェルに対してプログラムを 書いていくことで、文法的な部分やクラス間のインターフェースの異常をすぐに確認できます。しかも十分な速度で実行結果が返ってくるため、Java言語を 使って実装した場合よりも高速に実装が進められるという声が増えています。また文法的にもJava言語はスクリプト言語と比べ、実現したいことを書く場合に遠回りをしなければならないなど、記述するにも面倒な点があります。

Javaのもう1つの面はプラットフォームであるという点です。Javaの実行環境であるJava仮想マシンは多くの環境で稼動できます。Java 言語で作成したプログラムを実行するのはJava仮想マシンなので、OSというプラットフォームには直接依存しないのです。

Java言語を使ったWebアプリケーションの開発では開発のやりやすさやOSのライセンスの関係から、開発環境と実際にアプリケーションを稼動させる本番環境は違ったOSを使うことが多いのではないでしょうか。そういったサーバ用途でのJavaプラットフォームは非常に成功しています。また携帯電 話など組み込み用途でもJavaプラットフォームが成功したのは、Java仮想マシンによって稼働する対象を依存させなかったためといえるでしょう。

Java SE 6ではJavaプラットフォーム上で動作するスクリプト言語エンジンを公式にサポートし、現行のJavaプラットフォームの言語的な弱さをそれによって補完しています。

Java SE 7では、さらにプラットフォームの強化が進められる予定です。例えばJava One 2007で大々的に取り上げられていたJava FX Scriptと呼ばれるGUI作成用のスクリプト言語は、JavaプラットフォームにおけるGUIの作成を強化することを目的に作られました。すでにこち らは多くのWebサイトで取り上げられていますので、ご存知の方も多いでしょう。Java One 2007では他にもJava SE 7における重要な拡張が取り上げられていました。

Javaプラットフォームで開発する際、ライブラリの利用で困ったことはありませんか？

Javaプラットフォームは様々な環境で動作できるため、多くのライブラリが開発されてきました。しかし現在のJavaプラットフォームではライブラリを利用する上でいくつか問題があります。

問題点1：JARという配布形式はpublicを指定したクラスをすべて参照できる

JARによるライブラリの配布は、ライブラリ内部のクラスにはすべて公開したいが、ライブラリの外部からは参照させたくないクラスを制限することができません。クラスにpublic識別子をつけてしまうと同一クラスローダー上のすべてのクラスから参照できてしまうのです。

もちろんこれはライブラリのパッケージの作成の際に気をつければ回避できます。しかしライブラリがオープンソースプロジェクトの成果物である場合、 バージョンがあがるたびにパッケージの公開／非公開のメンテナンスをする必要があるため、非常に不便です。このような場合は、あまり参照されたくはないと してもパッケージの制限を変更せずに公開したまま開発することも多いでしょう。

しかし開発者は本来は触ってはいけないクラスであると常に意識しなければなりません。そしてライブラリ作成者としては本来触ってほしくない非公開のAPIを、ライブラリ内で参照させるためやむを得ずpublicとしていることがあります。このようなAPIはライブラリ作成者は「Aというパッケージは 利用しないでください」とドキュメントとして残したり、あえてAPIのドキュメントを作成しないことでライブラリの外部には公開していないという意図を示 しています。

では、ライブラリの利用者はその意図に気づけるでしょうか？

ライブラリ作成者はもちろん公開していないと意識しているので、どんどん作り変えられていることもあるでしょう。そうした場合、ライブラリを更新するたびに利用者は苦労をするのではないでしょうか。

問題点2：バージョンの違うライブラリのロードを制御できない

ライブラリの組み合わせによっては、使いたいライブラリを使えなくなる場面がでてきました。

例えば、あるライブラリAはバージョン1.2.0のライブラリBを必要としていますが、ライブラリCはバージョン2.0.0のライブラリBを必要とするなど、1つのアプリケーションの中であるライブラリの複数のバージョンを利用したい場合などです。

同一のクラスローダー上ではバージョンの違うクラスを同時に扱うことはできませんから、この場合はどちらかのライブラリの使用をあきらめなければなりません。

問題点3：JARという配布形式では依存しているライブラリを1つにまとめて扱えない

   JARはその内部にJARを持つような構造をサポートしていません。あるライブラリが依存するJARを一緒にまとめて配布することはできても、まとめて1つのファイルとしてJVMにロードすることはできません。そのためどのライブラリがどのJARに依存しているか、ひと目では理解しにくいことが増えました。

JARファイルの中のMANIFEST.MFの中にJARファイルが利用しているライブラリを記述することができますが、関連するライブラリを1つにまとめて扱うことができればそちらの方が楽ではないでしょうか。

問題点4：JVMを止めることなく機能の追加／削除をできない

アプリケーションサーバはWARなどで配布されているアプリケーションを追加／削除する機能を持っているものも多いのですが、Java SEではこういった機能を標準ではサポートしていませんでした。デスクトップ用途のアプリケーションではこういった機能に関するライフサイクルのサポート があれば常に最新の環境をユーザへ提供することができます。