Java 

JavaTM RMI リリースノート
for J2SETM 5.0

 RMI  の目次
J2SETM 5.0 の拡張機能
スタブクラスの動的な生成
このリリースでは、実行時にスタブクラスを動的に生成するためのサポートが追加されたので、リモートオブジェクト用のスタブクラスを事前に生成する Java(TM) Remote Method Invocation (Java RMI) スタブコンパイラ (rmic) を使う必要がなくなりました。以前のバージョンで実行されるクライアントをサポートする必要があるリモートオブジェクトに対しては、rmic を使用して事前にスタブクラスを生成する必要があることに注意してください。

コンストラクタ、または java.rmi.server.UnicastRemoteObject クラスまたは java.rmi.activation.Activatable クラスの static メソッド exportObject 1 を使用してアプリケーションがリモートオブジェクトをエクスポートしても、そのリモートオブジェクトのクラスに対応する生成済みスタブクラスが読み込まれない場合、リモートオブジェクトのスタブは、呼び出しハンドラとして java.rmi.server.RemoteObjectInvocationHandler 付きの java.lang.reflect.Proxy インスタンスとなります。そのクラスは、動的に作成されます。

java.rmi.server.ignoreStubClasses システムプロパティを true に設定することで、動的に作成されたスタブクラスを既存のアプリケーションが無条件で使用するように配置できます。つまり、スタブクラスが事前に生成されていたかどうかにかかわらず使用できるということです。このプロパティが true に設定されていると、生成済みスタブクラスが使用されることはありません。

注:

  • リモートオブジェクトがリリース 5.0 よりも前のクライアントを持っている場合、そのリモートオブジェクトは、rmic で事前に生成されたスタブクラスを使う必要があります。または、クライアントが ClassNotFoundException を入手して、リモートオブジェクトのスタブの直列化を復元します。リリース 5.0 より前のクライアントは、動的に生成されたスタブクラスのインスタンスを読み込むことができません。このようなクラスには RemoteObjectInvocationHandler のインスタンスが含まれていますが、このリリースより前のバージョンでは利用できないからです。

  • J2SE 5.0 リリースより前のバージョンでは、リモートオブジェクトをエクスポートする際にそのリモートオブジェクトのクラスに対応する生成済みスタブクラスを読み込むことができないと、java.rmi.StubNotFoundException がスローされます。動的に生成されたスタブクラスのサポートが追加されたため、生成済みのスタブクラスを持たないリモートオブジェクトをエクスポートしても、そのまま処理が続行されます。リリース 5.0 より前のバージョンをサポートするサーバアプリケーションを配備しているユーザは、エクスポート時にスタブクラスがなくてもエラーは報告されませんが、引き続きそのサーバのリモートオブジェクトのクラスに対応するスタブクラスを必ず事前に生成する必要があります。代わりにこのようなエラーは、動的に生成されたスタブクラスの直列化を復元するときに、5.0 より前のリリースのクライアントに報告されます。

1 static メソッド UnicastRemoteObject.exportObject(Remote) は、java.rmi.server.RemoteStub を返すように宣言されるので苴褧Iに生成されたスタブクラスを使うリモートオブジェクトをエクスポートする場合に使用することはできません。動的に生成されたスタブクラスのインスタンスは、java.lang.reflect.Proxy インスタンスであり、RemoteStub に割り当てられません。

標準 SSL/TLS ソケットファクトリクラス
今回のリリースでは、標準の Java RMI ソケットファクトリクラスである javax.rmi.ssl.SslRMIClientSocketFactory と javax.rmi.ssl.SslRMIServerSocketFactory が追加されています。これらのクラスでは、Java Secure Socket Extension (JSSE) を使って、Secure Sockets Layer (SSL) プロトコルまたは Transport Layer Security (TLS) プロトコルを介して通信します。これらのソケットファクトリクラスでは、Java RMI で簡単に JSSE を使う方法が提供されるので、リモートメソッド呼び出しのための整合性、暗号化による機密性、サーバ認証、およびクライアント認証 (任意) を強化できます。Java RMI でのカスタムソケットファクトリの使い方の詳細は、「Java RMI によるカスタムソケットファクトリの使用」チュートリアルを参照してください。設定を含む JSSE の詳細は、「JSSE リファレンスガイド」を参照してください。

inetd/xinetd から rmid または Java RMI サーバを起動する
System.inheritedChannel メソッドにより提供される新しい機能によって、アプリケーションは、仮想マシン (VM) を起動したプロセスから継承されるチャネル （java.nio.channels.SocketChannel または java.nio.channels.ServerSocketChannelなど) を取得することができます。この継承チャネルは、SocketChannel の場合は単一の着信接続を行うため、ServerSocketChannel の場合は複数の着信接続を受け入れるために使用できます。その結果、inetd (Solaris(TM) オペレーティングシステム) または xinetd (Linux) によって起動された Java ネットワーキングアプリケーションは、inetd/xinetd から継承された SocketChannel または ServerSocketChannel を取得できるようになりました。

この機能の追加によって、Java RMI 起動デーモン rmid は、inetd/xinetd からの起動をサポートするように拡張されたため、着信した接続要求を受け取ったときにのみ、起動することができます。この機能をサポートするための rmid の拡張機能についての詳細は、rmid (Solaris オペレーティングシステム用) のツールページを参照してください。rmid を起動するように inetd を構成する方法についての詳細は、「rmid を起動する inetd の構成」チュートリアルを参照してください。

Java RMI を使用するアプリケーションは、inetd または xinetd から起動されるように設計することもできます。この技法を実装する方法の例については、「inetd から起動されるサービスの設計」チュートリアルを参照してください。

直列化の拡張機能
J2SE 5.0 におけるオブジェクト直列化の拡張および改善の詳細は、「直列化リリースノート」を参照してください。
J2SE 5.0 での変更
rmic の現在のデフォルトのスタブプロトコルのバージョン -v1.2
生成されたクラスに使用される JRMP スタブプロトコルのバージョンを指定するオプションなしで rmic が実行されると、前のリリースの -vcompat オプションの代わりに -v1.2 オプションが指定されているかのように実行されます。

つまり、この変更によって、デフォルトでは、1.2 スタブプロトコルのバージョンでのみ実装された、どのようなスケルトンクラスもスタブクラスも rmic によって生成されないということです。JDK 1.1 で実行されるクライアントをサポートするためにリモート実装クラスを構築する必要がある場合は、-vcompat オプションを明示的に指定する必要があります。(さらに、上記のようにリモート実装クラスがリリース 5.0 より前のバージョンで実行されるクライアントをサポートする必要がない場合は、そのようなクラスのために rmic を実行する必要はありません。)

これらのコマンド行オプションについての詳細は、rmic のツールドキュメント (Solaris および Linux用、Windows 用) を参照してください。

rmic がクラスパス内の任意のソースファイルをコンパイルすることはない
以前のリリースでは、入力クラスファイルの処理中に、クラスパス内にある任意の .java ソースファイルを rmic がコンパイルしようとすることがありました。リリース 5.0 では、rmic は自ら生成したスタブ、スケルトン、またはタイクラス以外のソースファイルをコンパイルしようとすることはありません。

rmic に渡されるリモート実装クラスは、そのクラスが依存しているすべてのクラスおよびインタフェースと同様に、rmic が実行される前にすでに javac で正常にコンパイルされています。既存の構築手順がアプリケーションのソースファイルのいくつかをコンパイルする rmic の事前の動作に依存している場合は、rmic を実行する前に、必要なすべてのクラスが javac で正しくコンパイルされていることを確認するために、その構築手順を変更する必要があります。

以前のリリースでの拡張機能と変更
サーバ側スタックトレースがリモートの例外に保持される (1.4 以降)
Java RMI ランタイム実装が、以前のリリースで行っていたようにクライアント側スタックトレースを記入するだけでなく、リモート呼び出しからスローされる例外のサーバ側スタックトレース情報を保持するようになりました。したがって、そのような例外がクライアントコードにアクセス可能になると、そのスタックトレースには、元のサーバ側トレースデータと、それに続くクライアント側トレースのすべてが含まれることになります。

この機能は、J2SE 1.4 の java.lang.Throwable の新しい「スタックトレース情報へのプログラムによるアクセス」機能によって可能になりました。これには、デフォルトの直列化形式の Throwable のスタックトレースデータ部分の作成が含まれます。クライアント側 Java RMI ランタイム実装は、この機能と連携するために、以前のリリースのように単にクライアント側トレースで上書きするのではなく、クライアント側トレースを非整列化されたサーバ側トレースに追加します。

サーバアプリケーションによっては、パフォーマンスまたは機密性に関する理由により、リモート呼び出しの結果として整列化される例外に、J2SE 1.4 の例外のデフォルトの直列化形式の一部としてサーバ側スタックトレースデータが付随することを防ぐ必要がある場合があります。そのような場合は、実装に固有のシステムプロパティである 

sun.rmi.server.suppressStackTraces
を「true」に設定すると、サーバ側 Java RMI ランタイム実装によって、リモートメソッドの呼び出しの結果、現在の仮想マシンからスローされたすべての例外のスタックトレースが消去されます。

RMIClassLoader 用サービスプロバイダインタフェース (1.4 以降)
java.rmi.server.RMIClassLoader の一部の static メソッドの動作は、新しいサービスプロバイダインタフェース java.rmi.server.RMIClassLoaderSpi のインスタンスに委譲されています。サービスプロバイダを設定して、指定したアプリケーションに対する Java RMI の動的クラスローディングの動作を強化することができます。デフォルトでは、サービスプロバイダは、RMIClassLoader の static メソッドすべての標準動作を実装しています。詳細については、RMIClassLoader および RMIClassLoaderSpi のクラスドキュメントを参照してください。

動的なサーバホスト名 (1.4 以降)
java.rmi.server.hostname プロパティが動的に更新され、その後のエクスポートで新しいホスト名を使用するように指示できるようになりました。したがって、新しいホスト名の値は、このプロパティが更新されたあとにエクスポートされるオブジェクトのスタブに格納されます。

HTTP フォールバックの構成可能性の増加 (1.4.1 以降)
実装固有のシステムプロパティ sun.rmi.transport.proxy.eagerHttpFallback が追加され、Java RMI のデフォルトのソケットファクトリが HTTP トンネリングにフォールバックする際により細かく制御できるようになりました。このプロパティは、デフォルトのソケットファクトリを構成して、最初の (直接的な) 接続試行によってスローされた SocketException が HTTP トンネリングのトリガになるようにします。さらに「厳しい」このフォールバックのストラテジは、承認されていないポートへの接続試行を無視するのではなく拒否するようなファイアウォールを取り扱うときに有用である可能性があります。

java.rmi.Naming.list メソッドは返される名前にスキーマを付加することはない (1.4.1 以降)
以前のリリースでは、Naming.list メソッドは、返された文字列の配列に含まれる名前にスキーマ rmi: を付加していました。現在の Naming.list の実装はその仕様に合致しており、URL 形式の名前の配列を返しますが、スキーマコンポーネントは含まれません。

java.rmi.activation.ActivationGroupDesc (1.3 以降)
グループのクラス名を返す getClassName メソッドが、システムのデフォルトグループ実装を示す null を返すことが可能になりました。これまでは、記述子の構築時にデフォルトのグループ実装が選択された場合、getClassName メソッドは内部の実装クラスの名前を返していました。

この変更に対応するために、仮想マシン 1.3 で稼動するアプリケーションが新たな起動可能オブジェクトを ActivationSystem に登録する場合、rmid も 1.3 を実行できるようにアップグレードする必要があります。これは、1.3 より前の rmid では新たに登録された起動可能オブジェクトを起動できないためです。

Java RMI スタブコンパイラ rmic (1.3 以降)
rmic (Solaris および Linux 用、Windows 用) では、スタブのデフォルトの生成先ディレクトリが、パッケージ名の付いた、現在の作業ディレクトリのサブディレクトリになりました。「-d」オプションを指定しない場合は、現在の作業ディレクトリ「.」が引数として指定されていると見なされます。デフォルトの生成先ディレクトリをオーバーライドしても、「-d」が使われます。

IDL および IIOP のスタブを生成するために、「-idl」と「-iiop」オプションが追加されました。

Java RMI 起動デーモン rmid (1.3 以降)
デフォルトでは、rmid (Solaris および Linux 用、Windows 用) は現在、セキュリティポリシーファイルを要求します。

リモートオブジェクトの直列化 (1.2.2 以降)
1.2.2 より前は、アンエクスポートされたリモートオブジェクトを RMI 呼び出しに渡そうとすると、java.rmi.StubNotFoundException が返されました。RMI ランタイムでリモートオブジェクト実装を対応するスタブに置換しているときに、スタブオブジェクトの検索に失敗するとこの例外が発生していました。1.2.2 以降のリリースでは、アンエクスポートされたリモートオブジェクトを RMI 呼び出しに渡しても、例外は発生しません。スタブの代わりに、このリモートオブジェクトが直列化されます。リモートオブジェクト実装が直列化可能でない場合は、アンエクスポートされたオブジェクトを RMI 呼び出しに渡そうとすると、java.rmi.RemoteException および入れ子にされた例外 java.io.NotSerializableException が返されます。
Copyright © 2004 Sun Microsystems, Inc.All Rights Reserved. 
コメントの送付先: rmi-comments@java.sun.com 		 Sun