Java™ 2 SDK, v1.4 での AWT の拡張機能

1.4.2 バグの修正
1.4.1 バグの修正
新しいフォーカスサブシステム
推奨されない Focus メソッド
タイムスタンプを必要とする ActionEvent (およびその他のイベント)
ヘッドレスサポート
マルチスクリーンのサポートに必要なウィンドウ中心配置 API
新しい全画面排他モード API
Windows NT でのビデオドライバの Sync Out of Range エラー 非装飾フレーム
マウスホイールのサポート
Frame のプログラミングズーム
サイズ変更時の動的なレイアウト
コンポーネントリスナーリストへのアクセス
ドラッグ&ドロップの変更点
Solaris での 64 ビット対応
一貫性のない DLL 警告
DrawingSurface API の削除
新しい InputEvent キー修飾子
Choice メニューのドロップダウン動作の変更点
Choice コンポーネントはレイアウトマネージャー制限に適合

1.4.2 バグの修正

4648702: Microsoft Windows 2000 および Windows XP 上では、SCROLLBARS_BOTH フィールドが、true に設定されていても、TextArea が、垂直スクロールバーにしか表示されない場合がある。

4636311: リリース 1.3.1 および 1.4 上で Runnable から実行すると、モーダルダイアログがハングアップする場合がある。

4385243: ANSI コードページ (Hindi など) を含まない Microsoft Windows ロケールにテキストを入力できない。

1.4.1 バグの修正

4690831: ゲームアプレットが Internet Explorer では正常に再ペイントできない。

4627627: フォーカストラバーサルキーが awt.properties から Preferences API へ移動された。

4636548/4639735: Microsoft Windows 2000 でスクリーンセーバーが起動している場合、リリース 1.4 がクラッシュする。

4379138: いくつかのデッドキーのキーイベントに対する Linux 上の問題。

4627542: Swing アプリケーションは、Linux ではインターナショナルキーボードをサポートしない。

4395157: 1.3 の Linux では、アプレットで「%」を入力できない。

4669873: Microsoft Windows のホッパーベータに報告されている、ドラッグ&ドロップのバグ。ドラッグ&ドロップ中にアプリケーションが短時間フリーズする。リリース 1.4.1 の最終リリースで修正されている。

新しいフォーカスサブシステム

この変更に関連するバグ追跡レポート: 4290675。

これまでのフォーカスアーキテクチャーは、フォーカスサブシステムに新しく置き換わりました。新しいフォーカスサブシステムは、プラットフォームが異なるために生じるフォーカス関連のバグや、AWT と Swing コンポーネントとの非互換性に対応しています。詳細については、「フォーカスモデル仕様」を参照してください。

ここから javadoc を参照してください。

ヘッドレスサポート

この変更に関連するバグ追跡レポート: 4281163。

メインフレームや専用サーバーのような環境では、多くの場合、ディスプレイ、キーボード、マウスをサポートしていません。GraphicsEnvironment の新規メソッド isHeadless および isHeadlessInstance により、ヘッドレスサポートが可能になっています。これらのメソッドでは、ディスプレイ、キーボード、マウスがグラフィック環境でサポートされるかどうかを示します。

ヘッドレスには次のような API の変更があります。

(*)Applet、Button、Checkbox、Choice、FileDialog、Label、List、Menu、MenuBar、MenuComponent、MenuItem、PopupMenu、Scrollbar、ScrollPane、TextArea、TextComponent、Frame、Window、Dialog、JApplet、JFrame、JWindow、JDialog、および TextField。Canvas および Panel は、空のピアを割り当てて軽量コンポーネントとして扱うことができるので、このような例外をスローする必要がありません。

ヘッドレスを実装した環境を実行するには、java コマンド行に次のプロパティーを指定します。

  -Djava.awt.headless=true
このプロパティーが設定されず、ディスプレイ、キーボード、およびマウスがサポートされない場合、デフォルトではヘッドレス実装が使用されます。

例外が正しくキャッチされるように、ソースコードでヘッドレスをチェックする必要があります。たとえば、ヘッドレスを実装する以前の Foo クラスの実装は次のとおりです。

class Foo {
  static Choice c = new Choice();  // could throw HeadlessException
}
ヘッドレス実装後の新しい Foo の実装は、static ブロックに次のように記述します。 
class Foo {
  static Choice c;
  static {
    try {
      c = new Choice();
    catch (HeadlessException e) {
        ...
    }
  }
}

新しい全画面排他モード API

この変更に関連するバグ追跡レポート: 4189326。

新しい全画面排他モードの API は、ウィンドウシステムを一時停止して画面に直接描画できる高性能グラフィックスをサポートします。全画面モードとは、AWT の Frame、Window、Dialog を画面に合わせて広げるだけの機能とはまったく異なり、ビデオメモリーの内容をアプリケーションで完全に制御するグラフィックモードです。アプリケーション側でグラフィックカードに描画内容、描画方法、描画タイミングを指示します。このモードはいつも利用できるわけではありません。オペレーティングシステムによっては、まったく実装できないこともあります。また、オペレーティングシステムの中には、グラフィックカードがこの機能をサポートしている場合にのみ利用できるものもあります。ただし、このモードはパフォーマンスに大きな影響を与えるので、Windows ではハードウェアのページ反転機能を有効にしておく必要があります。

全画面排他 API モードの使い方とコード例については、ここを参照してください。

API の変更

Windows NT でのビデオドライバの Sync Out of Range エラー

この変更に関連するバグ追跡レポート: 4452207。

Intel 810 グラフィックコントローラ搭載の Dell Optiplex GX110 で Windows NT を使用している場合に、表示モードを高解像度にして複数回変更すると、ビデオドライバから「sync out of range」というメッセージが表示されることがあります。これは、(DirectX) ビデオドライバのバグが原因です。この問題に対しては、次のようないくつかの回避方法があります。

非装飾フレーム

この変更に関連するバグ追跡レポート: 4038769。

アプリケーションによっては、ネイティブフレーム装飾がない方が良い場合があります。たとえば、さまざまなプラットフォームで実行されるアプリケーションで同じ Look&Feel が必要な場合や、エンドユーザーがネイティブオペレーティングシステムに接触することをプログラマが望まない場合です。

このリリースでは、Java アプリケーションからフレーム装飾の作成を無効にできます。このモードをオンにすると、ネイティブなタイトルバー、システムメニュー、ボーダー、またはネイティブオペレーティングシステムに依存するその他の画面コンポーネントは表示されません。AWT と Swing コンポーネントは透過的に機能します。

java.awt.Frame への変更:

    public void setUndecorated(boolean undecorated)

    public boolean isUndecorated()

java.awt.Dialog への変更:

    public void setUndecorated(boolean undecorated)

    public boolean isUndecorated()

マウスホイールのサポート

この変更に関連するバグ追跡レポート: 4289845。

マウスホイールとは中央のボタンの代わりにホイールがあるもので、マウスホイールによるスクロール機能が Java の組み込みサポートに新しく加わりました。java.awt.event.MouseWheelEvent クラスは、Java アプリケーションでマウスホイールのスクロールをシームレスにサポートすることを可能にします。このとき、再コンパイルは必要ありません。また、新しいインタフェース java.awt.event.MouseWheelListener を使ってマウスホイールの動作をカスタマイズすることもできます。

Linux でマウスホイールを使用する場合は、ここを参照してください。

Frame のプログラミングズーム

この変更に関連するバグ追跡レポート: 4071554。

これまでは、Frame をプログラム上でズーム (最大化) する方法はありませんでした。このリリースでは、この機能が追加されました。

新規インタフェース java.awt.event.WindowStateListener が導入されています。

java.awt.Frame への変更:

    public static final int MAXIMIZED_HORIZ;

    public static final int MAXIMIZED_VERT;

    public static final int MAXIMIZED_BOTH;

    public synchronized void setMaximizedBounds(Rectangle bounds)

    public Rectangle getMaximizedBounds()

    public synchronized void setExtendedState(int state)

    public synchronized int getExtendedState()

java.awt.event.WindowEvent への変更:

    public static final int WINDOW_STATE_CHANGED;

    public WindowEvent(Window source, int id, Window opposite, int oldState, int newState)

    public WindowEvent(Window source, int id, int oldState, int newState)

    public int getOldState()

    public int getNewState()

java.awt.AWTEvent への変更:

    public final static long WINDOW_STATE_EVENT_MASK;

java.awt.Toolkit への変更:

    public boolean isFrameStateSupported(int state) throws HeadlessException

java.awt.Window への変更:

    public synchronized void addWindowStateListener(WindowStateListener l)

    public synchronized void removeWindowStateListener(WindowStateListener l)

    public synchronized WindowStateListener[] getWindowStateListeners()

    protected void processWindowStateEvent(WindowEvent e)

java.awt.event.WindowAdapter への変更:

    public void windowStateChanged(WindowEvent e)

java.awt.AWTEventMulticaster への変更:

    public static WindowStateListener add(WindowStateListener a, WindowStateListener b)

    public static WindowStateListener remove(WindowStateListener l, WindowStateListener oldl)

サイズ変更時の動的なレイアウト

この変更に関連するバグ追跡レポート: 4077991。

これまでは、どのプラットフォームでもウィンドウの大きさの動的な変更はサポートされていませんでした。たとえば、大きさの静的な変更がオンの Windows NT では、ウィンドウの大きさを変更すると、ドラッグが終了したときにレイアウトが再計算されました。このリリースでは、この機能が修正されて新規デスクトッププロパティー awt.dynamicLayoutSupported が追加されました。動的レイアウトが有効なときは、Container は大きさの変更に合わせてコンポーネントを連続的に配置します。無効なときは、大きさの変更が終了したあとでレイアウトが検証されます。

java.awt.Toolkit の API の変更点:

    public void setDynamicLayout(boolean dynamic)

    protected boolean isDynamicLayoutSet()

    public boolean isDynamicLayoutActive()

コンポーネントリスナーリストへのアクセス

この変更に関連するバグ追跡レポート: 4290704。

これまでは、書き込み可能なすべての AWT コンポーネントの状態は読み取ることもできました。たとえば、コンポーネント API には書き込み専用のプロパティーはありません。イベントリスナーはまったくの例外でした。AWT イベントリスナーは、次の 1 組のメソッドによって JavaBeansTM の規則に従って管理されます。XXXEventListener インタフェースを実装するリスナーの addXXXListener メソッドと removeXXXListener メソッド。

リスナーリストそのものへのアクセス機能は提供されませんでした。リスナーリストを含むフィールドはパッケージ private で、リスナーリストの内容を戻すメソッドは提供されませんでした。これは Swing やほかの AWT クライアントにおける問題の原因になっていました。

バージョン 1.3 の Java 2 SDK の問題を軽くするために、Component に getListeners メソッドを追加し、リスナーリストを定義した Swing クラスにも追加しました。getListeners メソッドは、クラスを使って特定のリスナーリストを指定します。たとえば、addFocusListener により追加されたすべてのリスナーを取得するには、getListeners(FocusListener.class) と記述します。

リスナーリストを公開するこのアプローチにより、AWT/Swing public API 全体の変更を最小限にすることができました。これはすべての JavaBeans の方法にすることは意図しておらず、PropertyChangeListener (addPropertyChangeListener("myProperty", myListener) のように単一プロパティーに追加できる) は扱いませんでした。このリリースでは、イベントリスナーにアクセスできる、より完成度の高いソリューションが設計されています。概念上は、次の 2 点が変更されています。

新規クラス java.awt.event.AWTEventListenerProxy があります。

java.awt.Toolkit の API の変更点:

    public PropertyChangeListener[] getPropertyChangeListeners()

    public synchronized PropertyChangeListener[] getPropertyChangeListeners(String propertyName)

    public AWTEventListener[] getAWTEventListeners()

    public AWTEventListener[] getAWTEventListeners(long eventMask)

ドラッグ&ドロップの変更点

この変更に関連するバグ追跡レポート: 4407057 および 4426750。

Solaris および Linux 版の Java 2 Standard Edition, SDK 1.3 では、いくつかの AWT 重量 Component がマウス中央ボタン経由でデフォルトドラッグ動作を表現していました (アプリケーションが java.awt.dnd API 経由でこれらの Components を DragSource として識別しない場合を含む)。このような Component は Motif ピアを使って実装され、Motif はマウスの中央ボタンのドラッグ動作をデフォルトでこれらのピアに提供します。

AWT の設計上の問題と Motif ライブラリのバグのために、このデフォルトの動作は安定性に関するさまざまな問題の原因になっていました。特殊な機能のために AWT とドラッグ&ドロップの安定性を危険にさらし続けるよりは、この機能を実装内で明示的に無効にすることを選択しました。

それでも java.awt.dnd API を使えば、開発者はアプリケーション内でこれらの Component を DragSource として識別できます。これは実用目的にかなっており、サポートされています。このアプローチは、デフォルトの Motif 動作に依存するよりも、常に優れています。Solaris と Linux だけではなく、すべてのプラットフォームでこれらの Component のためにドラッグサポートを実現できるからです。

Solaris マシンでの 64 ビット対応

この変更に関連するバグ追跡レポート: 4295833。

64 ビットの Solaris アプリケーションは、32 ビットではなく 64 ビットを使ってメモリーをアドレス指定します。これにより、仮想メモリーの容量を増やして大容量のアプリケーションが使用できるようなります。このリリースの AWT は 64 ビットまで対応しています。詳細は、ここを参照してください。

一貫性のない DLL 警告

この変更に関連するバグ追跡レポート: 4414004。

アジア系言語版の Windows NT もインストールされているマシンに英語版の VC++ 6.0 をインストールした場合、TextArea コンポーネントにアジア系言語版のテキストをレンダリングすると、文字化けが発生することがあります。この問題は、アジア系言語版の Windows NT 4.0 が動作しているマシンに Microsoft Exchange または Microsoft Office 97 をインストールしても発生することがあります。この問題は日本語版の Windows NT で報告されましたが、中国語や韓国語版といった非ラテン系言語版でも発生すると思われます。

この問題は、プログラムのインストール時にアジア系言語版 Riched32.dll が英語版に置き換わったために生じました。Riched32.dll をアジア系言語版に置き換えると、問題は解決します。

DrawingSurface API の削除

この変更に関連するバグ追跡レポート: 4293646。

sun.awt.DrawingSurface API が削除されました。これまで公表されたことはありませんが、使用している開発者もいます。この API の機能は JAWT に置き換えられています。詳細は、「AWT Native Interface」にある説明を参照してください。

マルチスクリーンのサポートに必要なウィンドウ中心配置 API

この変更に関連するバグ追跡レポート: 4463949。

マルチヘッドシステムで動作する Xinerama 対応のアプリケーションでさまざまな問題が発生し、バグレポートが作成されています。マルチヘッド環境でボーダーのないまたは小さいモニターを使用している場合は、モニターどうしが接して 1 つの巨大なディスプレイのようになります。この場合、「適切に」中心配置されたウィンドウが複数の画面にまたがる場合があります。ほかのマルチヘッド環境が通常の CRT モニターを使用している場合、実際の表示領域の間に数インチのパッケージングが発生します。この場合、複数画面にまたがるウィンドウでイライラすることになります (特に、Solaris ログイン画面などのウィンドウを一方のモニターにドラッグできない場合)。つまり、ウィンドウを Xinerama 環境のどこに中心配置するかを伝える方法がありませんでした。

この問題に対処するため、X グループが API を追加しました。Xinerama ユーザーは「中心配置したい」ウィンドウをどこに中心配置するかを指定でき、Xinerama 対応アプリケーションの開発者はそのようにコーディングできます。

このリリース以前は、次のようなウィンドウ中心配置方法で、デフォルト 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 です。getCenterPoint と getMaximumWindowBounds はどちらも、ヘッドレスモードのときに HeadlessException をスローします。

新しい InputEvent キー修飾子

この変更に関連するバグ追跡レポート: 4387938 および 4421515。

これまで、InputEvent 修飾子は、キーボードとマウスボタンに対して同じ値を持っていました。状況によっては、どのキーやボタンが押されたのかを区別できないことや、同時に複数押されたときに判別できないことがありました。このような状況としては、同時に複数のマウスボタンが押されたときや、マウスイベントが修飾キーによって変更されたときなどがあります。

この欠陥を解決するために、次の定数が InputEvent に追加されました。

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

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

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

DragSourceDragEvent に新しい getGestureModifiersEx メソッドが追加されました。

Choice メニューのドロップダウン動作の変更点

この変更に関連するバグ追跡レポート: 4462677。

Choice ドロップダウンメニューの動作が、JDK 1.3.1 から 1.4 の間で変更されました。1.3.1 では、Choice バーのどこをクリックしてもドロップダウンメニューが表示されました。1.4 では、Choice バーの右にある矢印をクリックする必要があります。Choice バーのほかの部分をクリックしても何も起きません。Choice バーの記号も、バーから矢印とバーを組み合わせたものに変更されました。最後に、ドロップダウンメニューが親の外まで展開されて、その部分をクリックすると、その下にあるアプリケーションが前面に表示されます。ただし、これは Solaris での動作であり、Windows では異なります。

Choice コンポーネントはレイアウトマネージャー制限に適合

この変更に関連するバグ追跡レポート: 4288285。

1.4 より前のリリースでは、AWT Choice ウィジェットは、レイアウトマネージャーが指定したサイズを無視する場合がありました。このリリースでは、レイアウトマネージャーの制限に従います。

推奨されないフォーカスメソッド

この変更に関連するバグ追跡レポート: 4476300。

このリリースで導入された新しいフォーカスサブシステムでは、AWT および Swing の高度なアプリケーションでキーボードフォーカスを扱うために、新しいアーキテクチャーと用語が導入されました。このプロジェクトの前は、フォーカス関連の API の多くで使用法と用語に整合性がなく、ドキュメントにも不備があったために、不完全な設計の UI につながっていました。新しいアーキテクチャーが導入された現在では、これらの API のうち特に使用を避けるべきものがあります。

次の定数とメソッドは推奨されなくなりました。

タイムスタンプを必要とする ActionEvent (およびその他のイベント)

この変更に関連するバグ追跡レポート: 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 に追加されました。

Copyright © 1993, 2013, Oracle and/or its affiliates. All rights reserved.