機械翻訳について

Java SE 1.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組のメソッドによって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点が変更されています。

新規クラス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が削除されました。 これまで公表されたことはありませんが、使用している開発者もいます。 この機能は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, 2025, Oracle and/or its affiliates. All rights reserved.