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 内部クラスとしてサポートされるバッファーストラテジには次の 2 つがあります。java.awt.Component.FlipBufferStrategy および java.awt.Component.BltBufferStrategy。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 組のメソッドによって 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 点が変更されています。
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 が削除されました。これまで公表されたことはありませんが、使用している開発者もいます。この 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_MASKCTRL_DOWN_MASKMETA_DOWN_MASKALT_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)getButtongetMouseModifiersTextDragSourceDragEvent に新しい 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_PROPERTYjavax.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 に追加されました。