 |
|
|
| 前のページ 1 2 3 次のページ
|
|
| Java SE 7における重要な拡張〜それはモジュラリティの向上
|
Java SE 7では、このような問題点に対応するための機能強化として「モジュラリティの向上」が進められる予定です。
モジュラリティとはモジュールの作りやすさのことです。本連載では「モジュールとはいくつかのライブラリやクラスを集め、まとまりのある機能を持った部品」と定義します。またライブラリは一般的に配布されているJARファイルのことを指し、いくつかのライブラリを組み合わせて作られたソフトウェアの部品構成をモジュールと呼びます。
さて、Java SE 7で謳われている「モジュラリティの向上」ですが、3つのJSR（注1）が提案されています（表1）。
- JSR 294：Java Language Modularity Support with Superpackage
- SuperpackageによるモジュールのAPIの公開、非公開の制御。
- JSR 277：Java Module System
- JARを拡張したJAM（Java Application Module）によるモジュール性の向上
- JSR 291：Dynamic Component Support for Java SE
- モジュールをダイナミックに追加、削除するなどのアプリケーションのライフサイクルの管理
表1：3つのJSR
※注1：
JSRとはJava標準化機関であるJCP（Java Community Process）にて提案されている仕様のことで、JCPにてJSRがJava標準にふさわしいかどうかを議論し、ここで選ばれることでJava標準が決められています。そしてJava標準となったJSRはJavaプラットフォームへ実装されます。
JSR 294はモジュール開発をする上での容易性をあげるための言語的な拡張が宣言された仕様で、JSR 277とJSR 291はモジュールの配布のための仕様です。
|
| 問題点1の解決案：JSR 294 SuperpackageによるモジュールのAPIの公開／非公開の制御
|
JSR 294では上記のpublic識別子をつけたクラスが公開されすぎる問題を解決するために考えられたJSRです。下記のコード例はJava One 2007で解説されていた例です。
例1：Java One 2007で解説されたsuperpackage.java
superpackage jdk {
member package java.util;
member package java.io;
member package sun.io; // 実際に開発されている実装
export java.util.*; // 外部へ公開するパッケージ
export java.io.*;
}
Sun MicrosystemsのJDKでは、本来パッケージ名が「sun」ではじまるパッケージは開発者が使用すべきパッケージではありません。しかし、現在リリースされているJavaでは利用することが可能です（Eclipseなどの開発環境ではこれらのパッケージを利用できないように隠蔽化しています）。上記のsuperpackageなどを使えばこれらのパッケージを隠蔽化することができます。
このsuperpackageが記述されたコードを「super-package.java」として作成し、コンパイルすると「.spkg file」として生成されます。各実装である「.java」をコンパイルすると「.class」ファイルが生成されますが、そのときにどのクラスがどのsuperpackageへ属するのか、という情報が埋め込まれます。
JavaのRuntimeの実行時にはこの「.spkg file」と「.class」の情報を参照して、パッケージの制限をします。これは「.spkg file」を削除してもパッケージにアクセスできないようにするためです。またコンパイル時にも非公開のAPIを参照していないかどうか確認できるようになるでしょう。このsuperpackageの機能を利用することで、公開したいAPIと非公開なAPIを明示できます。
|
| 問題点2・3の解決案：JARを拡張したJAMによるモジュール性の向上（JSR 277）
|
JSR 277では新たなモジュールの単位としてJARを拡張したJAM（Java Application Module）が提唱されています。JAMでは前述したsuperpackageとアノテーションを用いて、モジュールの読み込みをバージョンを指定することで制御することができます。
では、JAMにおけるsuperpackageとアノテーションの例を記述し、それぞれ解説していきます。
まず例2です。ここではA.JAMに内包した「icons/graphics1.jpg」や「icons/graphics2.jpg」というリソースをJAMの外部へ公開するように宣言しています。
例2：A.JAMのsuperpackage.java
@Version(“1.2.3”) // このJAMのバージョンを「1.2.3」と宣言
@ExportResources({ // JAM内部のリソースの公開を宣言
"icons/graphics1.jpg",
"icons/graphics2.jpg"})
superpackage org.foo.soap { //「org.foo.soap」というパッケージにあるクラスを外部へ公開するように宣言
member org.foo.soap;
export org.foo.soap.*;
}
例3のようにバージョンを指定していない場合は、ロードされているJAMの中で最新のバージョンのものをB.JAMから利用します。
例3：B.JAMのsuperpackage.java
superpackage org.foo.xml {
member org.foo.xml;
import org.foo.soap; // B.JAMが利用するパッケージを宣言
}
例4ではアノーテーションにより利用するパッケージのバージョンを指定しています。この例では「1.3」と明示しているため、A.JAMは利用されません。
例4：C.JAMのsuperpackage.java
superpackage org.foo.xml {
member org.foo.xml;
@VersionConstraint(“1.3”) // C.JAMが利用するパッケージを宣言
import org.foo.soap;
export org.foo.xml;
}
JAMファイルは複数のJARを内包できるようにしているので、モジュールごとのライブラリの管理を容易にしています。これまで普通のJavaアプリケーションではクラスパスを指定するにはすべてのJARファイルを指定する必要がありました。しかしJAMを使用すればJAMの中でクラスパスを指定できるので、これまでのようなクラスパス地獄に陥ることが少なくなるでしょう。
その他JSR 277ではモジュールとして利用しやすいようにリポジトリという概念が提案されています。
読者の方の中にはmavenをお使いの方も多いと思います。mavenにもリポジトリという概念があり、mavenを使うとWeb上で配布されているモジュールを自動的に取得できます。JSR 277でもそれと同様の仕組みが提案されています。
モジュールをURL Repositoryという形で公開することで利用者は自動的にモジュールを取得し、Local Repositoryにモジュールを格納します。Local Repository内はBootstrap Repository、Global Repository、Application Repositoryと階層分けがされています。
アプリケーションからモジュールを呼び出す場合は、「Application Repository → Global Repository → Bootstrap Repository」と参照します。このため複数のアプリケーションで同一のモジュールを使用する場合など、管理がしやすいようになっています。
|
前のページ 1 2 3 次のページ
|
|
|
|
|
著者プロフィール
株式会社チェンジビジョン 近藤 寛喜
モデリングツールJUDEを開発しているチェンジビジョンにて、プロジェクトの現在を見える化し、状況を共有することで現場で起きている問題を解決するためのツールTRICHORDを開発している。以前からオープンソースのプロジェクトに興味を持ち、特にEclipseプラットフォームに心酔している。最近はゲームの操作感を刷新したWiiリモコンを使って何か面白いUIが作れないか模索している。
|
|
|
|
|
|
