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コンポーネントはレイアウト・マネージャ制限に適合
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の変更があります。
java.awt.HeadlessException
が導入されています。これは、RuntimeException
から派生したUnsupportedOperationException
から派生しています。これにより、新しい例外をスローするメソッドの既存の実装でシグネチャを変更する必要がなくなります。java.awt.GraphicsEnvironment
に追加されています。
public static boolean isHeadless() public boolean isHeadlessInstance()
Applet
のコンストラクタと重量コンポーネント(*)はすべてHeadlessException
をスローするように変更されています。コンストラクタのjavadocタグは、すべてこのRuntimeException
を反映するように変更されています。Robot
コンストラクタはAWTException
をスローします。Toolkit
とGraphicsEnvironment
のメソッドのうち、フォント、イメージング、および印刷を除く多くのメソッドが変更されて、ディスプレイ、キーボード、マウスがサポートされない場合にHeadlessException
をスローするようになりました。このようなメソッドのjavadocタグはすべてこのRuntimeException
を反映するように変更されています。HeadlessException
をスローするように変更されています。isHeadless
がtrueを返す場合のみ、HeadlessException
がスローされます。すべてのjavadocコメントでこれを明記するようにしてください。(*)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) { ... } } }
この変更に関連するバグ追跡レポート: 4189326。
新しい全画面排他モードのAPIは、ウィンドウ・システムを一時停止して画面に直接描画できる高性能グラフィックスをサポートします。全画面モードとは、AWTのFrame
、Window
、Dialog
を画面に合わせて広げるだけの機能とはまったく異なり、ビデオ・メモリーの内容をアプリケーションで完全に制御するグラフィック・モードです。アプリケーション側でグラフィック・カードに描画内容、描画方法、描画タイミングを指示します。このモードはいつも利用できるわけではありません。オペレーティング・システムによっては、まったく実装できないこともあります。また、オペレーティング・システムの中には、グラフィック・カードがこの機能をサポートしている場合にのみ利用できるものもあります。ただし、このモードはパフォーマンスに大きな影響を与えるので、Windowsではハードウェアのページ反転機能を有効にしておく必要があります。
全画面排他APIモードの使い方とコード例については、ここを参照してください。
APIの変更
java.awt.DisplayMode
が導入されています。java.awt.GraphicsDevice
への変更:
public void setFullScreenWindow(Window w) public Window getFullScreenWindow() public boolean isDisplayChangeSupported() public void setDisplayMode(DisplayMode dm) public DisplayMode getDisplayMode() public DisplayMode[] getDisplayModes()
java.awt.image.BufferStrategy
の内部に実装されました。java.awt.BufferCapabilities
はバッファ・ストラテジを作成するときに使用できます。同様に、新規クラスjava.awt.ImageCapabilities
は、特定構成のイメージ機能を定義するときに利用できます。Canvas
またはWindow
からバッファ・ストラテジを作成および使用できます。protected内部クラスとしてサポートされるバッファ・ストラテジには、java.awt.Component.FlipBufferStrategy
とjava.awt.Component.BltBufferStrategy
の2つがあります。createBufferStrategy
メソッドが呼び出されると、この2つの内部クラスのどちらかがCanvas
またはWindow
で使用されます。どちらが使用されるかは、(ストラテジがある場合は)ストラテジの作成時に提供されるBufferCapabilities
オブジェクトによって決まります。特定のコンポーネントで使用されるバッファ・ストラテジを取得するには、getBufferStrategy
メソッドを使用します。この変更に関連するバグ追跡レポート: 4452207。
Intel 810グラフィック・コントローラ搭載のDell Optiplex GX110でWindows NTを使用している場合に、表示モードを高解像度にして複数回変更すると、ビデオ・ドライバから「sync out of range」というメッセージが表示されることがあります。これは、(DirectX)ビデオ・ドライバのバグが原因です。この問題に対しては、次のようないくつかの回避方法があります。
-Dsun.java2d.noddraw=true
を指定してDirectDrawを無効にする。1152 X 864 8 85 1152 X 864 16 85 1152 X 864 24 85 1280 X 1024 8 70,72,75,85 1280 X 1024 16 70,72,75,85 1280 X 1024 24 70,75,85 Bad Color (Unsatisfactory appearance in terms of color) 1024 X 768 8 60,70,72,75,85
この変更に関連するバグ追跡レポート: 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でマウス・ホイールを使用する場合は、ここを参照してください。
Component
に一度に表示できる量以上の内容がある場合(スクロールつまみがスクロール・トラック全体を占有していない)に、スクロール・バーは「スクロール可能」と見なされます。setWheelScrollEnabled(false)
を使用します。TextArea
、Choice
、FileDialog
、List
があります。このようなコンポーネントでは、ネイティブ・ピアによってマウス・ホイール・スクロールが制御されます。Component
は、MouseWheelEvent
が有効になっているContainer
が見つかるまでContainer
階層にマウス・ホイール・イベントを伝えます。これは通常、ScrollPane
です。マウス・ホイール・イベントは、MouseWheelEvent
が有効になっているComponent
に伝えられます。MouseWheelListener
を追加して、マウスがComponent
上にあるときにマウス・ホイールを動かした場合の動作をカスタマイズすることもできます。マウス・ホイール・イベントをネイティブ処理できるComponent
の場合、クライアントはネイティブ処理を避けるためにマウス・ホイール・イベントを消費できます。java.awt.ScrollPane
は、デフォルトでMouseWheelEvent
が有効になるように変更されています。ScrollPane
がMouseWheelEvent
を受け取ると、含んでいるComponent
を正しくスクロールします。この機能は、新規メソッドsetWheelScrollingEnabled
で無効にすることもできます。軽量サポート
MouseWheelListener
を持つ最初の先祖にマウス・ホイール・イベントを伝えます。MouseWheelListener
をJComponent
に追加してカスタム・イベント処理を行うことができます。javax.swing.JScrollPane
が変更されています。java.awt.ScrollPane
と同じように、setWheelScrollingEnabled
を使用して、この機能を無効にすることもできます。APIでは、マウス・ホイールをサポートするため、すでに説明した新規クラスや新規インタフェース以外にも次の点が変更されています。
java.awt.AWTEvent
への変更:
public final static long MOUSE_WHEEL_EVENT_MASK;
java.awt.AWTEventMulticaster
への変更:
public void mouseWheelMoved(MouseWheelEvent e) public static MouseWheelListener add(MouseWheelListener a, MouseWheelListener b) public static MouseWheelListener remove(MouseWheelListener l, MouseWheelListener oldl)
java.awt.Component
への変更:
public synchronized void addMouseWheelListener(MouseWheelListener l) public synchronized void removeMouseWheelListener(MouseWheelListener l)
java.awt.ScrollPane
への変更:
public void setWheelScrollingEnabled(boolean handleWheel) public boolean isWheelScrollingEnabled()
java.awt.Robot
への変更:
public synchronized void mouseWheel(int wheelAmt)
Linuxでマウス・ホイールを認識させるには、/etc/X11/XF86Config
ファイルに2つの変更を行う必要があります。「Pointer」セクションで次のような変更を行います。
次の行を追加します。
ZAxisMapping 4 5
プロトコルを「imps/2」に変更します(使用しているホイール・マウスによって異なります)。
この変更に関連するバグ追跡レポート: 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組のメソッドによってJavaBeansの規則に従って管理されます。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点が変更されています。
getFooListeners
メソッドをAWTクラスとSwingクラスでのadd/remove方法に追加。java.util.EventListenerProxy
による、PropertyChangeListener
およびVetoableChangeListener
のサポート(単一プロパティを待機するものを含む)。新規クラス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
のためにドラッグ・サポートを実現できるからです。
この変更に関連するバグ追跡レポート: 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が削除されました。これまで公表されたことはありませんが、使用している開発者もいます。この機能はJAWTに置き換えられています。詳細は、「AWT Native Interface」にある説明を参照してください。
この変更に関連するバグ追跡レポート: 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
に追加されました。
このメソッドは、各種プラットフォームで次のように動作します。
getCenterPoint
はプライマリ・ディスプレイの中心座標を返します。getCenterPoint
はプライマリ・ディスプレイの中心点を返します。getCenterPoint
はそれらの値を返します。それ以外の場合は、仮想座標空間の中心点を返します。(実際には、CDEがこれをデフォルトで設定するため、ほとんどの場合は設定されています。)JDK 1.4から、中心配置のための正しいコードは次のようになります。
frame.setLocation(getCenterPoint() - size of window / 2);
GraphicsEnvironment
に追加されたもう1つのメソッドはgetMaximumWindowBounds
です。getCenterPoint
とgetMaximumWindowBounds
はどちらも、ヘッドレス・モードのときにHeadlessException
をスローします。
この変更に関連するバグ追跡レポート: 4387938および4421515。
これまで、InputEvent
修飾子は、キーボードとマウス・ボタンに対して同じ値を持っていました。状況によっては、どのキーやボタンが押されたのかを区別できないことや、同時に複数押されたときに判別できないことがありました。このような状況としては、同時に複数のマウス・ボタンが押されたときや、マウス・イベントが修飾キーによって変更されたときなどがあります。
この欠陥を解決するために、次の定数がInputEvent
に追加されました。
SHIFT_DOWN_MASK
CTRL_DOWN_MASK
META_DOWN_MASK
ALT_DOWN_MASK
ALT_GRAPH_DOWN_MASK
BUTTON1_DOWN_MASK
BUTTON2_DOWN_MASK
BUTTON3_DOWN_MASK
次のメソッドがInputEvent
に追加されました。
MouseEvent
のクラス仕様が更新されました。次の定数もMouseEvent
に追加されました。
次のメソッドがMouseEvent
に追加されました。
MouseEvent(Component source, int id, long when, int modifiers, int x, int y, int clickCount, boolean popupTrigger, int button)
getButton
getMouseModifiersText
DragSourceDragEvent
に新しいgetGestureModifiersEx
メソッドが追加されました。
この変更に関連するバグ追跡レポート: 4462677。
Choice
ドロップ・ダウン・メニューの動作が、JDK 1.3.1から1.4の間で変更されました。1.3.1では、Choiceバーのどこをクリックしてもドロップ・ダウン・メニューが表示されました。1.4では、Choice
バーの右にある矢印をクリックする必要があります。Choice
バーのほかの部分をクリックしても何も起きません。Choice
バーの記号も、バーから矢印とバーを組み合わせたものに変更されました。最後に、ドロップ・ダウン・メニューが親の外まで展開されて、その部分をクリックすると、その下にあるアプリケーションが前面に表示されます。ただし、これはSolarisでの動作であり、Windowsでは異なります。
この変更に関連するバグ追跡レポート: 4288285。
1.4より前のリリースでは、AWT Choice
ウィジェットは、レイアウト・マネージャが指定したサイズを無視する場合がありました。このリリースでは、レイアウト・マネージャの制限に従います。
この変更に関連するバグ追跡レポート: 4476300。
このリリースで導入された新しいフォーカス・サブシステムでは、AWTおよびSwingの高度なアプリケーションでキーボード・フォーカスを扱うために、新しいアーキテクチャと用語が導入されました。このプロジェクトの前は、フォーカス関連のAPIの多くで使用法と用語に整合性がなく、ドキュメントにも不備があったために、不完全な設計のUIにつながっていました。しいアーキテクチャが導入された現在では、これらのAPIのうち特に低品質なものは非推奨になりました。
次の定数とメソッドは非推奨になりました。
javax.swing.FocusManager.FOCUS_MANAGER_CLASS_PROPERTY
javax.swing.FocusManager.disableSwingFocusManager()
javax.swing.FocusManager.isFocusManagerEnabled()
javax.swing.JComponent.requestDefaultFocus()
javax.swing.JComponent.isManagingFocus()
javax.swing.JComponent.setNextFocusableComponent(Component)
javax.swing.JComponent.getNextFocusableComponent()
java.awt.Component.isFocusTraversable()
java.awt.Component.hasFocus()
javax.swing.SwingUtilities.findFocusOwner(Component)
この変更に関連するバグ追跡レポート: 4434193。
新しいフォーカス・アーキテクチャには、先打ちメカニズムも含まれています。このメカニズムでは、あるKeyEvent
でフォーカス移動が開始されると、移動が完了するまで、後続のKeyEvent
は配信されなくなります。この機能の設計は、各種イベントのUTCタイムスタンプに基づいています。移動を開始したイベントより後のタイムスタンプを持つイベントは待ち行列に入れられて移動の解決が保留されますが、それより前のタイムスタンプを持つイベントはそうされません。
この機能を実現するために、フォーカス・コードでは、現在処理中のイベントのタイムスタンプを常に監視しています。この処理中にフォーカス移動が開始された場合は、そのタイムスタンプを使用できます。ただし、現在処理中のイベントにタイムスタンプがない場合は、システムの現在の時間が使用されます。この時間は通常、イベントが実際に発生した時間よりもかなり進んでいるため、実際には役立ちません。結果として、先打ちメカニズムは失敗し、フォーカス移動が完了する前にKeyEvent
が配信されます。
この問題はActionEvent
でもっとも多く発生していました。ActionEvent
は、基となるInputEvent
に対応して生成される、高レベルのセマンティック・イベントです。InputEvent
にはタイムスタンプが関連付けられていましたが、ActionEvent
はタイムスタンプを持っていませんでした。したがって、タイムスタンプを格納できるようにActionEvent
APIが拡張されました。また、実装も更新され、ActionEvent
のタイムスタンプと、基盤となるInputEvent
のタイムスタンプとが一致するようになりました。
次のメソッドがActionEvent
に追加されました。
次のActionEvent
メソッドが変更されました。
ActionEvent(Object source, int id, String command)
ActionEvent(Object source, int id, String command, int modifiers)
getWhen
メソッドがInvocationEvent
に追加されました。
InvocationEvent
のInvocationEvent(Object, Runnable)
コンストラクタとInvocationEvent(Object, Runnable, Object, boolean)
コンストラクタが変更されました。
新しいInputMethodEvent(Component, int, long, AttributedCharacterIterator, int, TextHitInfo, TextHitInfo)
コンストラクタがInputMethodEvent
に追加されました。 getWhen
メソッドも追加されています。
次のInputMethodEvent
コンストラクタが変更されました。
InputMethodEvent(Component, int, AttributedCharacterIterator, int, TextHitInfo, TextHitInfo)
InputMethodEvent(Component, int, TextHitInfo, TextHitInfo)
.最後に、次のメソッドがEventQueue
に追加されました。