![]() |
JavaTM RMI リリースノート |
RMI の目次 |
J2SE 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 におけるオブジェクト直列化の拡張および改善の詳細は、「直列化リリースノート」を参照してください。
以前のリリースでの拡張機能と変更
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 の例外のデフォルトの直列化形式の一部としてサーバ側スタックトレースデータが付随することを防ぐ必要がある場合があります。そのような場合は、実装に固有のシステムプロパティである
を「true」に設定すると、サーバ側 Java RMI ランタイム実装によって、リモートメソッドの呼び出しの結果、現在の仮想マシンからスローされたすべての例外のスタックトレースが消去されます。sun.rmi.server.suppressStackTraces
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 |
![]() |