Java

J2SETM 1.4 Beta 2 での変更点

  英語版
このドキュメントでは、以前の J2SE 1.4 Beta 2 リリースでの重要な変更点について説明します。これ以降での変更点については、J2SE 1.4 Beta 3 での変更点を参照してください。

目次

AWT
Java 2D
Java Platform Debugger Architecture
Java 印刷サービス
Java Web Start
Image I/O
Swing
VM
国際化
ログ機能
セキュリティ
ネットワーク機能
Java RMI
ツール
Accessibility

AWT

非推奨となったフォーカス関連メソッド

この変更に関する bugtraq レポート: 4476300

このリリースで採用された新規フォーカスサブシステムでは、複雑な AWT および Swing アプリケーション内でキーボードフォーカスを処理するための、新たなアーキテクチャおよび用語が導入されました。 このプロジェクト以前においては、多数のフォーカス関連 API の使用方法および用語が一貫しておらず、ドキュメント化も適切に行われていなかったため、設計された UI の質はよくありませんでした。 新たなアーキテクチャの採用により、これらの API の中で特に標準からはずれたものが推奨されなくなりました。

推奨されなくなった定数およびメソッドを、以下に示します。

タイムスタンプが必要になった ActionEvents (および他のイベント)

この変更に関する bugtraq レポート: 4434193

新たなフォーカスアーキテクチャには、フォーカスの転送を開始する KeyEvent に続く KeyEvent が、転送が完了するまでは送信されないことを保証する先行入力機構が含まれます。 この機能の設計は、さまざまなイベントの UTC タイムスタンプに基づいています。 開始イベント以降のタイムスタンプを保持するイベントは、転送を保留にし、キューに格納されます。開始イベント以前のタイムスタンプを保持するイベントは、キューには格納されません。

この機能を実装するため、フォーカスコードは処理中のイベントのタイムスタンプを追跡します。 この処理中にフォーカスの変更が開始されると、タイムスタンプが使用可能になります。 ただし、現行のイベントがタイムスタンプを保持しない場合には、現行のシステム時刻が使用されます。 通常、この時刻は、イベントが実際に発生した時刻よりもずっと後なので、実際は使いものになりません。 このため、先行入力機構は失敗し、フォーカスの転送が完了する前に KeyEvent が送信されてしまいます。

この問題の発生するもっとも一般的なケースとして、ActionEvent を挙げることができます。ActionEvent は、基盤となる InputEvent に応答して生成される高度な意味上のイベントです。InputEvent は自らに関連付けられたタイムスタンプを保持しますが、ActionEvent はそうではありません。 このため、ActionEvent API が拡張されて、タイムスタンプに対応するようになりました。また、実装も更新され、ActionEvent のタイムスタンプと基盤となる InputEvent のタイムスタンプが等しくなります。

次のメソッドが、 ActionEvent に追加されました。

次の ActionEvent メソッドが変更されました。

getWhen メソッドが InvocationEvent に追加されました。

InvocationEvent のコンストラクタ InvocationEvent(Object, Runnable) および InvocationEvent(Object, Runnable, Object, boolean) が変更されました。

新規コンストラクタ InputMethodEvent(Component, int, long, AttributedCharacterIterator, int, TextHitInfo, TextHitInfo) が InputMethodEvent および getWhen メソッドに追加されました。

次の InputMethodEvent コンストラクタが変更されました。

また、次のメソッドが EventQueue に追加されました。

マルチスクリーンサポートに必須のウィンドウセンタリング API

この変更に関する bugtraq レポート: 4463949

多くのバグレポートで報告されているように、マルチヘッド対応システムで稼動する Xinerama 対応アプリケーションで問題が発生しています。 マルチヘッド環境の中には、境界がほとんどあるいはまったく存在しないモニターを使用するものがあります。このような環境では、表示が相互に接合して 1 つの巨大な表示になってしまう場合があります。 この場合、ウィンドウを中央に「適正に」配置しようとすると、複数の画面にまたがって表示されてしまいます。 多くのマルチヘッド環境では、実際の表示領域間に数インチのパッケージ領域を持つ、通常の CRT モニターが使用されます。 この場合、複数画面にまたがるウィンドウで奇妙な効果が発生します。特に、モニター間でドラッグできないウィンドウ (Solaris のログイン画面など) では、この問題が顕著です。 つまり、Xinerama 環境では、ウィンドウを中央に配置するための指針が存在しないことになります。

この問題を解決するため、Xinerama ユーザが「中央配置する」ウィンドウの中央位置を指定し、Xinerama 対応アプリケーションの開発者がそれに対応するコードを記述できるようにする API が X コンソーシアムにより追加されました。

これ以前のリリースで、ウィンドウを中央に配置する場合、次に示すようにデフォルトの GraphicsDevice の境界内で中央配置を行なっていました。 

     bounds = getDefaultScreenDevice().getDefaultConfiguration().getBounds();
     frame.setLocation(bounds / 2 - size of window / 2);
ウィンドウを Xinerama の座標空間全体の中央に配置する Xinerama システムでは、このコードによりウィンドウが「適正に」中央配置されます。

4356756 の JDK 修正により、このリリースから Xinerama システムでウィンドウが「適正に」中央配置されます。このシステムでウィンドウは最初のディスプレイの中央に配置します。

この機能を実現するため、 getCenterPoint メソッドが GraphicsEnvironment に追加されました。

このメソッドは、次のさまざまなプラットフォームで動作します。

JDK 1.4 では、中央配置用の適正なコードは次のようになります。 

     frame.setLocation(getCenterPoint() - size of window / 2);

GraphicsEnvironment に追加されたもう 1 つのメソッドは、 getMaximumWindowBounds です。 Headless モードの場合、getCenterPoint と getMaximumWindowBounds はどちらも HeadlessException をスローします。

新規 InputEvent キー修飾子

この変更に関する bugtraq レポート: 4387938 および 4421515

以前は、 InputEvent 修飾子は、キーボードとマウスボタンに対し、同じ値を保持していました。 特定の状況では、どちらが押されたのかまたはいつから複数のボタンが同時に押されているのかを識別する方法がありませんでした。 この状況には、一度に複数のマウスボタンを押した場合、または修飾キーを使用してマウスイベントを変更した場合が含まれます。

この問題に対処するため、InputEvent に次の定数が追加されました。

次のメソッドが InputEvent に追加されました。

MouseEvent のクラス仕様が更新されました。 次の定数の MouseEvent への追加も行われました。

MouseEvent の次のメソッドが追加されました。

DragSourceDragEvent は、 getGestureModifiersEx メソッドを新たに保持するようになりました。

Java 2D

イメージスケーリングのパフォーマンスの改善

これ以前のリリースで、drawImage 実装は、1:1 以外のスケーリング係数で呼び出されると、中間バッファを作成しました。中間バッファに格納されたイメージに対するスケーリング操作の実行後に、スケーリングされたイメージがデバイスにコピーされました。 中間バッファ用のメモリ割り当て、およびバッファとの間の追加コピー操作により、パフォーマンスが低下しました。 このリリースでは、Win32 環境の場合、スケーリングされたイメージの描画は、DirectDraw スケール操作により実行されます。DirectDraw では、スケーリングされたイメージは直接 VRAM に送信されます。 Solaris および Linux 環境では、スケーリングされたイメージは 1 度のコピー操作で直接送信先に転送されます。これらの新しい操作では、中間ソフトウェアバッファが使用されないため、メモリの追加割り当てやコピー操作は必要ありません。

高速化されたメモリ管理用の新規メソッド

システムの中には、高速化されたイメージで利用可能なメモリが厳しく制限される場合があります。 VolatileImage を使って作成されたイメージは、この種のメモリに格納されることがあります。 ディスプレイと同じサイズのオフスクリーンイメージは、オフスクリーンイメージに使用されていないすべてのメモリを占有してしまう場合があります。 これ以前のリリースでは、オフスクリーンイメージのユーザは、やはり高速化されたメモリ内で不要になったイメージをフラッシュできませんでした。 新しい GraphicsDevice.getAvailableAcceleratedMemory メソッドは、高速化されたメモリの利用可能なバイト数を返します。 新しい VolatileImage.flush メソッドは、オフスクリーンイメージにより消費されたシステムリソースをすべて解放します。

グレースケールイメージ形式 StaticGray、Index8Gray、および Index12Gray の描画品質および描画速度の向上

バグ 4455845、 4455825、および 4320850 を参照

Beta 2 以前のリリースでは、グレースケール形式 StaticGray、Index8Gray、および Index12Gray に表示品質上の問題がありました。 具体的には、イメージにディザリングノイズが含まれる、シェードが暗すぎる、グラデーションにすべてのシェードが表示されないなどの問題がありました。 これらの問題は、このリリースで解決されました。 StaticGray、Index8Gray、Index12Gray 形式のイメージの、より高品質な描画を行うことが可能になりました。 また、Java 2D パイプラインアーキテクチャの全般的な改善により、これらのイメージ形式をより高速に描画できます。

ほかの変更点については、Java 印刷サービスおよび Image I/O を参照してください。

Java Platform Debugger Architecture

ほかの言語のデバッグサポート

Java Platform Debugger Architecture が拡張されたため、Java 以外のプログラミング言語ソースを Java プログラミング言語ソースに翻訳し、あとからデバッグすることが可能になります。 以下の表に、新規 API、およびコメントの変更された API を示します。 この情報は、SourceDebugExtension に基づいています。

新規 API コメントの変更された API
JVMDI
GetSourceDebugExtension  
JDWP - ReferenceType (2) コマンドセット
SourceDebugExtension コマンド (12)  
JDWP - VirtualMachine (1) コマンドセット
SetDefaultStratum コマンド (19)  
JDI - VirtualMachine インタフェース
void setDefaultStratum(String stratum)  
String getDefaultStratum()  
JDI - ReferenceType インタフェース
String sourceNames(String stratum) String sourceName()
String sourcePaths(String stratum)  
List allLineLocations(String stratum, String sourceName) List allLineLocations()
List locationsOfLine(String stratum, String sourceName, int lineNumber) List locationsOfLine(int lineNumber)
List availableStrata()  
String defaultStratum()  
String sourceDebugExtension()  
JDI - Method インタフェース
List allLineLocations(String stratum, String sourceName) List allLineLocations()
List locationsOfLine(String stratum, String sourceName, int lineNumber) List locationsOfLine(int lineNumber)
JDI - Location インタフェース
  クラスコメント (ストラタ定義済み)
int lineNumber(String stratum) int lineNumber()
String sourceName(String stratum) String sourceName()
String sourcePath(String stratum)  
String sourcePath()  

Java 印刷サービス

ページダイアログでのマージンの表示

これ以前のリリースで、Java 印刷サービスページダイアログには、用紙のサイズ、種類、および向きといったページ書式を表す属性だけが表示されました。 このリリースから、クライアントがページダイアログでページのマージンを表す MediaPrintableArea 属性を設定できるようになりました。

Solaris および Win32 の PrintService 実装による、出力データ用 AUTOSENSE 文書様式サポート

プリンタがサポートする文書の種類が、ネイティブのオペレーティングシステムから JVM に報告できる文書の種類を含み、それより多い場合、AUTOSENSE は有用です。 たとえば、プリンタは PDF の直接印刷をサポートするが、Java 印刷サービスがそれを検出できない場合、そのプリンタを使用するアプリケーションは AUTOSENSE DocFlavor を使用して、印刷データをプリンタにスプールできます。 そのため、これが有効なのは、プリンタが、プリンタへの実データ送信をサポートすることを開発者が知っている場合だけです。 Solaris および Win32 の PrintService 実装では、要求属性 (用紙の向きなど) とともに AUTOSENSE を指定することはできません。これは、AUTOSENSE はいかなる方法でも解釈されず、プリンタに直接送信されるためです。

Java Web Start

バグ修正および機能拡張

Image I/O

アプリケーションクラスパス内のプラグインの自動検出

独自のプラグインを使用するクライアントは、アプリケーション実行時に、明示的に scanForPlugins を呼び出す必要はありません。これは、Image I/O が自動的にプラグインのクラスパスを走査するためです。 クライアントが走査する必要があるのは、プラグインが動的にクラスパスに追加される場合だけです。

Swing

ACTION_COMMAND_KEY プロパティを優先する AbstractButton.configurePropertiesFromAction

この変更に関する bugtraq レポート: 4457940

これ以前のリリースで、 AbstractButton メソッド configurePropertiesFromAction(Action) および configurePropertiesFromAction(Action, String[]) は ACTION_COMMAND_KEY プロパティを優先しませんでした。 このリリースで問題は解決されました。 このため、次に示す AbstractButton のサブクラス内の configurePropertiesFromAction メソッド用 javadoc が影響を受けます。

新規 AbstractDocument.replace メソッドのサポートの拡張

この変更に関する bugtraq レポート: 4458513

RFE 4431047 の一環として、 replace メソッドが AbstractDocument に追加されました。 このメソッドから remove および insertString (Document の変化に対応する、インタフェース内で定義されたメソッド) を起動できるようにするため、 writeLock の起動するときの制限が緩和されました。 これにより、replace と、以前のバージョンの AbstractDocument (remove および insertString のオーバーライドのみを実行する) とは互換性を保持します。

ヘッドレスモードで JPopupMenu.setVisible(true) によりスローされる HeadlessException

この変更に関する bugtraq レポート: 4401222

新規ヘッドレスモードの導入時に、 JPopupMenu.setVisible(true) が実装されました。このため、ヘッドレスモードで呼び出しが行われると、NullPointerException がスローされていました。 この問題は修正され、ヘッドレスモードではこの操作が実行できないことを示す HeadlessException が代わりにスローされるようになりました。

DefaultTableModel で name 引数に null が許容される

この変更に関する bugtraq レポート: 4474094

これ以前のリリースで、 DefaultTableModel.addColumn(Object) および DefaultTableModel.addColumn(Object, Vector) メソッドで name 引数に null を指定することはできず、指定すると IllegalArgumentException がスローされていました。 ほかの手段 (コンストラクタを使用するか、フィールドを直接操作する) では列名に null を指定することが可能であるように、addColumn メソッドでも null 値が許可されるようになりました。

processKeyEvent をオーバーライドしない JFrame、JDialog、および JApplet

この変更に関する bugtraq レポート: 4462408

Swing では、JComponent に対するキーバインドを登録することが可能です。以前のリリースでは、Swing のトップレベルコンポーネント ( JFrame、 JDialog、および JApplet) のいずれかにフォーカスが存在する場合、これらのトップレベルコンポーネントで processKeyEvent ( java.awt.Component で定義) をオーバーライドして、キーバインドをアクティブにする必要がありました。 java.awt.KeyEventPostProcessor の追加、および Swing によるこの機能 ( RFE 4389332) の利用により、Swing のトップレベルコンポーネントでこれらのメソッドをオーバーライドする必要はなくなりました。 このリリースから、これらのメソッドはトップレベルから削除されており、現在は継承という方法が取られています。

JWindow コンストラクタでのドキュメントヘッドレス例外

この変更に関する bugtraq レポート: 4483258

このリリースではヘッドレスモードが追加されましたが、2 つの JWindow コンストラクタは、HeadlessException がスロー可能であることを示しませんでした。 これは、 Window(Window, GraphicsConfiguration) および JWindow(GraphicsConfiguration) 用のドキュメントで修正されています。

VM

シグナル連鎖機能

Java 2 SDK, Standard Edition, (J2SDK) v1.4 には、新しいシグナル連鎖機能が含まれています。 シグナル連鎖機能を使用すると、Java プラットフォームと、独自のシグナルハンドラをインストールするネイティブコードとの相互運用性が向上します。

シグナル連鎖機能には、2 つのコンポーネントが含まれます。

シグナル連鎖機能は、以前のバージョンの VM で発生したシグナル処理上の問題を解決するために導入されました。 バージョン 1.4 以前では、SIGBUS、SIGSEGV、SIGILL、SIGFPE、SIGPIPE、および SIGUSR1 用のインストール済みシグナルハンドラを VM で使用できませんでした。 これらのシグナルハンドラは、VM が使用するシグナルハンドラと衝突する可能性がありました。 アプリケーションからシグナルハンドラ自体 (JNI コード内など) を変更することはできません。これは、VM により生成されるシグナルの中に、VM から操作できないものが存在するためです。

J2SDK 1.4 の新しいシグナル連鎖機能は、VM 作成時にすべてのインストール済みシグナルハンドラを保存することにより、インストール済みシグナルハンドラをサポートします。 あとでシグナルが生成されると、VM はインストール済みハンドラを起動します。

シグナル連鎖機能は、アプリケーションと共に、共有ライブラリ libjsig.so のリンクおよびロードも行います。 このライブラリは、signal()、sigset()、および sigaction() などの呼び出しを遮断して、VM のシグナルハンドラの置き換えを防ぎます。 その代わり、これらの呼び出しにより新たなシグナルハンドラが保存されます。 その後、シグナル生成時に、VM は libjsig.so への呼び出しを行なって、保存されたハンドラを取得および起動します。

シグナル連鎖機能は、機能拡張要求 4381843 に対応するために導入されました。

国際化

より多くのエンコーディングサポート

J2SE 1.4 Beta 2 には、新たにサポートされる次のエンコーディング用のコンバータが含まれます。 これらの追加エンコーディングは、次のバグに対応しています: 4328178、4463536、および 4420751

java.text.Bidi のメンバ名の改訂

Beta 2 リリースでは、java.text.Bidi クラスのメンバ名が次のように変更されています。 
FLAG_DIR_DEFAULT_LTR -> DIRECTION_DEFAULT_LEFT_TO_RIGHT
FLAG_DIR_DEFAULT_RTL -> DIRECTION_DEFAULT_RIGHT_TO_LEFT
FLAG_DIR_LTR -> DIRECTION_LEFT_TO_RIGHT
FLAG_DIR_RTL -> DIRECTION_RIGHT_TO_LEFT
isLTR -> isLeftToRight
isRTL -> isRightToLeft
baseIsLTR -> baseIsLeftToRight

SimpleDateFormat パターンチェック

java.text.SimpleDateFormat クラスは、書式設定および構文解析中ではなく、コンストラクタまたは applyPatttern メソッド内でパターンをチェックするようになりました。このため、null や無効なパターンによる例外が早い段階でスローされます。 これは、4326988 に対応して行われた変更です。

ひらがなおよびカタカナ文字の適正な表示

Solaris オペレーティング環境用の Beta リリースでは、TextLayout.draw() で Bold、Italic、および Bolditalic を指定した場合、日本語のひらがな (/u3041 - /u309e) およびカタカナ (/u30a1 - /u30fe) が適正に表示されませんでした。 このバグ (4432069) は、Beta 2 リリースで修正されました。

ログ機能

java.util.logging.Level への追加

Logging API では、ログメッセージが「Level」を保持します。Level に含まれるレベル名は、エンドユーザへの表示が可能です。 ただし、これまでレベル名のローカライズはサポートされていませんでした。

サン以外により新規レベルの追加が行われる可能があるため、地域対応のリソースバンドルを、指定されたレベルと関連付ける標準機構を定義する必要があります。

次の変更により、Level クラスに対するレベル名の地域対応サポートが追加されました。

java.util.logging.Level クラス内の 1 つの新規コンストラクタおよび 2 つの新規メソッド

この変更に関連するバグレポートは、4385439 です。

java.util.logging.Logger の変更

Logger クラスには、コアロギングメソッド void log (LogRecord) が 1 つ含まれます。 これは、強力ですが使い方の難しいメソッドです。 このメソッドにより、Logger クラス内の多数の便利なメソッドがコアメソッドの単純なラッパーとして動作し、種々のログメッセージをさまざまな引数を使って簡単に記録できます。

次の 3 つの要素で、これら便利なメソッドは改訂されました。

これらの変更により、39 個存在した有用なメソッドは 25 個に減少し、わかりやすい形でグループ化されました。

以下に変更の概要を示します。

次の 21 個のメソッドが削除されました。

次の 7 つのメソッドが追加されました。

次の 3 つのメソッドの名前が変更されました。

また、log(LogRecord) の javadoc 仕様にいくらかの変更が加えられました。

この変更に関連するバグレポートは、4464348 です。

バックトレース回避策の削除

J2SDK 1.4 以前のリリースでは、Throwable クラスは、直列化時にスタックのバックトレースを保持しませんでした。 以前、ロギング API は、望ましくない回避方法を使って、直列化するときに LogRecord のバックトレースを保持していました。回避方法には、特殊メソッド LogRecord.getThrownBackTrace を呼び出して LogRecord のバックトレースを取得することが含まれていました。

このため、スタックバックトレースの適正な直列化および直列化解除が行われるよう、Throwable クラスに変更が加えられました。

現在では、LogRecord クラスの LogRecord.getThrownBackTrace メソッドなどの回避策を使用せずに済みます。

java.util.logging.LogRecord クラスで、次のメソッドが削除されました。

この変更に関連するバグレポートは、4451686 です。

FileHandler での追加モードのサポート

ロギング API には、FileHandler 出力クラスが含まれます。 これ以前のリリースでは、 FileHandler クラスは出力ファイルを常に新規作成していました。 このため、ロギング API の初期使用段階で、操作性の問題が表面化しました。 たいていの場合、出力ファイルを既存のファイルセットに追加できるようになることが望まれます。

この API 変更には、以下が含まれます。

次の 2 つの新規コンストラクタが java.util.logging.FileHandler に追加されました。加えて、javadoc クラスで新規ログ構成プロパティを指定することが可能になりました。

この変更に関連するバグレポートは、4452277 です。

セキュリティ

JavaTM Certification Path API

Java Certification Path API の変更点については、プログラマーズガイドの 「J2SE 1.4 Beta からの変更点」 を参照してください。

JAAS (JavaTM Authentication and Authorization Service)

「JAAS Tutorials」には、JAAS のさまざまな使用法が実例付きで解説されています。

「JAAS Reference Guide」 および 「JAAS LoginModule Developer's Guide」が更新されました。

JSSE (JavaTM Secure Socket Extension)

セキュリティ保護されたソケットプロトコルを選択する新規メソッド

SSLSocket および SSLServerSocket に新規メソッドが追加されたので、開発者は、ソケットで使用するセキュリティ保護されたソケットプロトコル (SSLv3 または TLSv1 あるいはその両方) を正確に選択できるようになりました。

これは、機能拡張番号 4478803 の一部として実装されました。

X509TrustManager メソッドの変更

X509TrustManager の isClientTrusted および isServerTrusted メソッドは、それぞれ checkClientTrusted および checkServerTrusted に名前が変更されました。 証明連鎖がこの TrustManager により信頼されない場合、checkClientTrusted および checkServerTrusted メソッドは、以前のメソッドのように boolean を返すのではなく例外をスローします。 これにより、実装は、信頼判定の失敗の原因を確認できます。 注: X509TrustManager は、J2SDK, v 1.4 で新たに追加されました。

これは、機能拡張番号 4329114 の一部として実装されました。

HostnameVerifier verify メソッドの変更

HostnameVerifier verify メソッドに対し、受信した証明書ではなく、ネゴシエーション済みの SSLSession が渡されるようになりました。 これにより、SSLSession では、ネゴシエーション済みの暗号群、交換済みの証明書などのクエリーを実行できます。 注: HostnameVerifier は、J2SDK, v 1.4 で新たに追加されました。

これは、機能拡張番号 4484246 の一部として実装されました。

Zip ファイルで入手可能なサンプルファイル

JSSE サンプルファイルは、zip ファイルで入手可能です。これは、Web でドキュメントを閲覧している場合や、サンプルをダウンロードしたい場合に便利です。

ネットワーク機能

HTTP ダイジェスト認証

HTTP ダイジェスト認証の実装が更新され、プロキシおよび起点サーバがサポートされるようになりました。また、RFC2617 で定義されたすべての機能を実装しました (auth-int モードを除く)。

ダイジェスト認証機構の動作を変更する、多数のシステムプロパティが追加されました。 これらのプロパティの詳細は、「Networking Properties」マニュアルを参照してください。

この変更は、バグレポート 4432213 に対応して行われました。

リテラル IPv6 アドレス書式の変更

J2SDK 1.4 Beta 2 では、IPv6 のリテラルアドレス処理がより明示的に行われます。 この変更は、IETF 標準 RFC 2373 (IPv6 アドレスアーキテクチャ) および RFC 2732 (URL によるリテラル IPv6 アドレス) に準拠するため、および新たに取得した IPv6 アドレスを使用する既存のアプリケーションとの下位互換性に関する潜在的な問題を最小限に抑えるために行われました。 基本的な規則は、URL/URI のコンテキスト (Java クラスローダおよび SocketPermissions のコンテキストで定義された 'codebase' を含む) では RFC 2732 に準拠し、それ以外の場合には RFC 2373 に準拠するというものです。

InetAddress および Inet6Address クラスの getByName(String host) および getAllByName(String host) メソッドでは、リテラル IPv6 アドレス内で 'host' が指定されると、RFC 2373 で定義されたアドレスが受け入れられます。 getHostAddress() メソッドでは、完全な書式が返されます。 完全な書式は、x:x:x:x:x:x:x:x のように定義されます。ここで「x」は、アドレスを構成する 8 つの 16 ビット数で表す 16 進数です。 この書式が選ばれたのは、ほかのテキストデータと組み合せて使用しても明確に識別できるためです。

URL クラスおよび URI クラスでは、コンポーネント化されたコンストラクタに対して、'host' パラメータがリテラル IP アドレスとして表現される場合、アドレスを RFC 2732 に規定されているように角括弧 ('[' および ']') で囲む必要があります。ただし、RFC 2373 で規定されたリテラル IPv6 アドレス書式も受け入れられます。 getHost() メソッドは、URL のホスト名を返します。 ホストの書式は、RFC 2732 に準拠します。リテラル IPv6 アドレスの場合、このメソッドにより、角括弧 ('[' および ']') で囲まれた IPv6 アドレスが返されます。

SocketPermission クラスでは、ホスト仕様にリテラル IPv6 アドレスが含まれる場合、RFC 2732 で定義された書式を使用する必要があります。IPv6 アドレスは、角括弧 ('[' および ']') で囲みます。 ただし、IPv6 アドレスを使用する既存のアプリケーションとの下位互換性に関する問題を最小限に抑えるため、明白なものはすべてクラスにより自動的に解決されます。

getByAddr メソッドの名前変更

J2SE 1.4 Beta の InetAddress および NetworkInterface クラスに導入された新規メソッド getByAddr は、J2SE 1.4 Beta 2 では getByAddress という名前になりました。

IPv6 リンクローカルアドレス

Beta リリースでは、IPv6 リンクローカルアドレスに送信または接続しようとすると、引数が無効であることを示す SocketException がスローされました。 これは、Beta 2 リリースで修正されました。 IPv6 リンクローカルアドレスに接続時に、ルーティングテーブルにより、使用するネットワークインタフェースが決定されます (netstat -r -A inet6)。

Java RMI

動的サーバホスト名

java.rmi.server.hostname プロパティを動的に更新することにより、以降のエクスポートでの新規ホスト名の使用を指示できるようになりました。 このため、新規ホスト名の値が、プロパティの更新後にエクスポートされるオブジェクトのスタブに含まれます。

プリミティブ Class オブジェクトの直列化

以前のリリースでは、RMI 呼び出しでプリミティブの Class オブジェクトを渡そうとすると、ClassNotFoundException がスローされました。 このリリースでは、プリミティブ型として Class オブジェクトを含むオブジェクトは、リモートメソッドパラメータまたは戻り値として渡すこと、および java.rmi.MarshalledObject インスタンスに格納することが可能になりました。

ツール

javac の新規 -Xswitchcheck オプション

javac バイトコードコンパイラは、switch ブロック内の「不成立の」case 文を検出するオプション -Xswitchcheck を新たにサポートします。 新しいオプションの詳細は、javac のマニュアルを参照してください。

新しい -Xcheck:jni オプション

Java アプリケーション起動ツールは、オプション -Xcheck:jni を受け付けます。 このオプションは、J2SE 1.2.2 の -Xcheck:jni (J2SE 1.3.0 で削除されました) に似ています。 このオプションを指定すると、Java Native Interface (JNI) 機能の追加チェックを行います。

Javadoc の変更

Beta 2 リリースでの Javadoc ツールの変更点は、「What's New in Javadoc 1.4」に記載されています。

Accessibility

AccessibleExtendedComponent.getAccessibleKeyBinding

インタフェース AccessibleExtendedComponent に新しいメソッド getAccessibleKeyBinding が含まれており、オブジェクトに関連するキーバインディングを返します。

新しい AccessibleRole 制約

クラス AccessibleRole には、以下の新しい制約が含まれています。

HTML の object タグに対するユーザ補助機能サポート

このリリースでは HTML の object タグに対するユーザ補助機能サポートが追加されています。 CTRL-t および SHIFT-CTRL-t を押すと、それぞれ HTML 文書中の object タグに関連する次のコンポーネント、および 1 つ前のコンポートにナビゲートします。 CTRL-SPACE を押すと、コンポーネントに関連付けられたデフォルトのアクションが起動します。

HTMLEditorKit キーボードリンクトラバーサル追跡のサポート

ユーザ補助機能は、HTMLEditorKit キーボードリンクトラバーサルを追跡する方法を必要としました。 この機能をサポートするために、定数 AccessibleContext.ACCESSIBLE_HYPERTEXT_OFFSET が追加されました。

ユーザ補助機能プロパティ

javax.accessibility.assistive_technologies プロパティで、JVM にロードするユーザ補助機能を指定します。

スクリーンリーダプロパティ

javax.accessibility.screen_reader_present プロパティを True に設定すると、Java プラットフォームライブラリは、システムにスクリーンリーダが存在することを認識します。 アプリケーションの開発者はこのプロパティをチェックできます。 アプリケーションが自己表明式で、さらにスクリーンリーダが存在する場合は、開発者は自己表明機能をオフにできます。
Copyright © 2001 Sun Microsystems, Inc. All Rights Reserved.

コメントやご意見をお寄せください。

Sun