![]() | Documentation Contents |
AWT Enhancements in the JavaTM 2 SDK, v1.4 |
1.4.2 Bug Fixes
1.4.1 Bug Fixes
New Focus Subsystem
Deprecated Focus Methods
ActionEvents (and Other Events) Need Timestamps
Headless Support
Window Centering API Required for Multiscreen Support
The New Fullscreen Exclusive Mode API
Sync Out of Range Error From Video Driver Under Windows NT Undecorated Frames
Mouse Wheel Support
Programmatic Zooming ofFrames
Dynamic Layout During Resize
Access to Component Listener Lists
Changes to Drag and Drop
64-Bit Compliance on Solaris
Inconsistent DLLs Warning
Removal of theDrawingSurfaceAPI
New InputEvent Key Modifiers
Change in Drop Down Behavior for Choice Menus
Choice Component Now Obeys Layout Manager Constraints
1.4.2 Bug Fixes4648702: On Microsoft Windows 2000 and Windows XP, a
TextAreawill sometimes display only a vertical scrollbar, even though theSCROLLBARS_BOTHfield is set totrue.4636311: Modal dialogs may hang when run from a
Runnableon release 1.3.1 and 1.4.1.4.1 Bug Fixes4385243: Unable to input text in Microsoft Windows locales that don't have an ANSI code page (such as Hindi).
4690831: Game applets fail to repaint properly with Internet Explorer.
4627627: Focus traversal keys moved from awt.properties to Preferences API.
4636548/ 4639735: Crash of release 1.4 when screensaver on Microsoft Windows 2000 is activated.
4379138: Problems on Linux with key events for some dead keys.
4627542: Swing applications don't support international keyboards under Linux.
4395157: Under Linux on 1.3, can't type "%" in applets.
New Focus Subsystem4669873: A drag and drop bug, reported on hopper-beta under Microsoft Windows, caused an application to briefly freeze during DnD and is fixed in the final release of 1.4.1.
Headless SupportThe bugtraq report that corresponds to this change is: 4290675.
A new focus subsystem replaces the previous focus architecture and addresses many focus-related bugs caused by platform inconsistencies, and incompatibilities between AWT and Swing components. See the new Focus Model Specification for further details.
See the javadoc here.
The bugtraq report that corresponds to this change is: 4281163.
Many environments, such as mainframe machines and dedicated servers, do not support a display, keyboard, or mouse. Headless support is enabled by the new
GraphicsEnvironmentmethodsisHeadlessandisHeadlessInstance. These methods indicate whether a display, keyboard, and mouse can be supported in a graphics environment.The API changes for headless include:
- A new public exception class,
java.awt.HeadlessException, is introduced. It is derived fromUnsupportedOperationException, which derives fromRuntimeException, so that existing implementations of methods that throw the new exception will not require signature changes.- Two new methods, are added to
java.awt.GraphicsEnvironment.public static boolean isHeadless() public boolean isHeadlessInstance()- The constructors of
Appletand all heavyweight components (*) are changed to throwHeadlessExceptionif a display, keyboard, and mouse are not supported by the toolkit implementation. All javadoc tags on all constructors are changed to reflect thisRuntimeException.- The
Robotconstructor throws anAWTExceptionif a display, keyboard, and mouse are not supported by the toolkit implementation.- Many of the methods in
ToolkitandGraphicsEnvironment, with the exception of fonts, imaging, and printing, are changed to throwHeadlessExceptionif a display, keyboard, and mouse are not supported. All the javadoc tags on these methods are changed to reflect thisRuntimeException.- Other methods that may be affected by lack of display, keyboard, or mouse support, are changed to throw
HeadlessException.- It should be worth noting that the
HeadlessExceptionis thrown if and only ifisHeadlessreturns true, and that all javadoc comments should specify this.(*)
Applet,Button,Checkbox,Choice,FileDialog,Label,List,Menu,MenuBar,MenuComponent,MenuItem,PopupMenu,Scrollbar,ScrollPane,TextArea,TextComponent,Frame,Window,Dialog,JApplet,JFrame,JWindow,JDialog, andTextField.CanvasandPaneldo not need to throw this exception since these can be given empty peers and treated as lightweights.To run our environment with a headless implementation, the follow property may be specified at the
javacommand line:-Djava.awt.headless=trueIf this property is not specified and a display, keyboard, and mouse are not supported, then headless implementation is used by default.Source code should check for headless, so that the exception may be caught gracefully. For example, see the following pre-headless implementation of the class
Foo:class Foo { static Choice c = new Choice(); // could throw HeadlessException }The new and improved implementation ofFooshould be placed in a static block:class Foo { static Choice c; static { try { c = new Choice(); catch (HeadlessException e) { ... } } }The New Fullscreen Exclusive Mode API
Sync Out of Range Error From Video Driver Under Windows NTThe bugtraq report that corresponds to this change is: 4189326.
The new full-screen exclusive mode API supports high performance graphics by suspending the windowing system so that drawing can be done directly to the screen. Full screen mode, which is entirely different from simply taking an AWT
Frame,Window, orDialogand expanding it to fit the screen, is a graphics mode whereby the application takes entire control over the contents of video memory. The application tells the graphics card what to draw, how to draw it, and when to draw it. This mode is not always available. On some operating systems, it may not be implemented at all. On other operating systems, it may only be available if the capability is supported by the graphics card. Nevertheless, this mode is critical for performance and is necessary for enabling hardware page-flipping on Windows.For a tutorial explaining how to use the full screen exclusive API mode with several code examples, see here.
API Changes:
- A new public final class,
java.awt.DisplayMode, is introduced.- Changes to
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()- The algorithm which handles direct video buffer control has been localized to a new class,
java.awt.image.BufferStrategy.- A new class
java.awt.BufferCapabilitiescan be used when creating a buffer strategy. Likewise, a new classjava.awt.ImageCapabilitiesis available to define the image capabilities of a specific configuration.- An application programmer can create and use a buffer strategy from a
Canvasor aWindow. There are two buffer strategies that are supported as protected inner classes:java.awt.Component.FlipBufferStrategyandjava.awt.Component.BltBufferStrategy. One of these two inner classes is used on theCanvasorWindowwhen thecreateBufferStrategymethod is called, depending on theBufferCapabilitiesobject supplied when creating the strategy (if any). To get the buffer strategy used by a particular component, thegetBufferStrategymethod is used.The bugtraq report that corresponds to this change is: 4452207.
If you have a Dell Optiplex GX110 using an Intel 810 Graphics Controller, under Windows NT, you may get a "sync out of range" message from the video driver if you change the display mode more than once and use a high display resolution. There is evidently a bug in the (DirectX) video driver that is causing this. There are several workarounds to this problem:
- Disable DirectDraw by using
-Dsun.java2d.noddraw=trueat the command line.- Do not change the display resolution more than once during the lifetime of a program that is intended to run on this hardware.
- Disallow the following display modes on this hardware:
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,85The bugtraq report that corresponds to this change is: 4038769.
For certain applications having no native frame decorations makes sense. For example, applications that will run across many platforms and that require that the look and feel is the same, or when the programmer does not want the end-user coming in contact with the native operating system.
This release allows a Java application to turn off the creation of frame decorations; no native titlebar, system menu, border, or other native operating system dependent screen components appear when this mode is enabled. AWT and Swing components work transparently.
Changes to
java.awt.Frame:public void setUndecorated(boolean undecorated) public boolean isUndecorated()Changes to
java.awt.Dialog:public void setUndecorated(boolean undecorated) public boolean isUndecorated()The bugtraq report that corresponds to this change is: 4289845.
The mouse wheel, with a scroll wheel in place of the middle mouse button, is enabled with new built-in Java support for scrolling via the mouse wheel. The
java.awt.event.MouseWheelEventclass enables seamless support for mouse wheel scrolling in Java applications with no recompiling required. Also, a newjava.awt.event.MouseWheelListenerinterface allows customization of mouse wheel behavior.Note, for those using the mouse wheel on Linux, see here.
- Scrolling Behavior:
- A scrollbar is considered "scrollable" if it is both showing and there is more content in the scrolling
Componentthan can be displayed at once, such that the scroll thumb does not occupy the entire scroll track.- It is possible for a scrollbar to be showing, but not be scrollable. Usually this occurs when a scrollbar is set to always be displayed.
- The scrollbar to be scrolled by the mouse wheel is determined as follows:
- If only one scrollbar is scrollable, it will be scrolled.
- If both a horizontal and a vertical scrollbar are scrollable, the vertical scrollbar will be scrolled.
- Wheel scrolling may be disabled altogether using
setWheelScrollEnabled(false).- Up/away-from-user rotations cause vertical scroll bars to scroll upwards, and horizontal scrollbars to scroll to the left. Just the opposite is true for down/towards rotations.
- No scrolling takes place if a scroll thumb is at the end of the scroll track.
- Heavyweight support:
- Some native peers with integrated scroll bars can handle mouse wheel scrolling by themselves. Examples on Windows includes
TextArea,Choice,FileDialog, andList. Such components will let their native peers handle wheel scrolling.Components which do not inherit any native mouse wheel behavior will propagate mouse wheel events up theContainerhierarchy until aContainerwithMouseWheelEvents enabled is found. This is typically aScrollPane. Mouse wheel events are delivered to theComponentwithMouseWheelEvents enabled.- Alternatively, client programmers may add
MouseWheelListeners to customize what happens when the mouse wheel is moved while the mouse is over aComponent. In the case ofComponents that already have native handling of mouse wheel events, clients may consume the mouse wheel event to avoid native handling.java.awt.ScrollPaneis modified to haveMouseWheelEvents enabled by default. When aScrollPanereceives aMouseWheelEvent, it will properly scroll its containedComponent. This functionality may be disabled with the newsetWheelScrollingEnabledmethod.Lightweight Support:
- Lightweight components will deliver mouse wheel events to their first ancestor with a
MouseWheelListener.MouseWheelListeners may be added to anyJComponentfor custom event handling.javax.swing.JScrollPaneis modified to properly scroll its viewed component. Likejava.awt.ScrollPane, this may be disabled usingsetWheelScrollingEnabled.- New API:
In addition to the new class and new interface previously mentioned, there are some other changes to the API to support the mouse wheel.
- Change to
java.awt.AWTEvent:public final static long MOUSE_WHEEL_EVENT_MASK;- Changes to
java.awt.AWTEventMulticaster:public void mouseWheelMoved(MouseWheelEvent e) public static MouseWheelListener add(MouseWheelListener a, MouseWheelListener b) public static MouseWheelListener remove(MouseWheelListener l, MouseWheelListener oldl)- Changes to
java.awt.Component:public synchronized void addMouseWheelListener(MouseWheelListener l) public synchronized void removeMouseWheelListener(MouseWheelListener l)- Changes to
java.awt.ScrollPane:public void setWheelScrollingEnabled(boolean handleWheel) public boolean isWheelScrollingEnabled()- Change to
java.awt.Robot:public synchronized void mouseWheel(int wheelAmt)- Linux Mouse Wheel Support:
For Linux to recognize your mouse wheel, two modifications to the
/etc/X11/XF86Configfile are required. Under the "Pointer" section:
Add the line:
ZAxisMapping 4 5Change the protocol to: "imps/2" (this will vary depending on your particular wheel mouse).
Programmatic Zooming of
FramesThe bugtraq report that corresponds to this change is: 4071554.
Previously there was no way to zoom (or maximize) a
Frameprogrammatically. This feature has been added to this release.The new interface
java.awt.event.WindowStateListeneris introduced.Changes to
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()Changes to
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()Changes to
java.awt.AWTEvent:public final static long WINDOW_STATE_EVENT_MASK;Changes to
java.awt.Toolkit:public boolean isFrameStateSupported(int state) throws HeadlessExceptionChanges to
java.awt.Window:public synchronized void addWindowStateListener(WindowStateListener l) public synchronized void removeWindowStateListener(WindowStateListener l) public synchronized WindowStateListener[] getWindowStateListeners() protected void processWindowStateEvent(WindowEvent e)Change to
java.awt.event.WindowAdapter:public void windowStateChanged(WindowEvent e)Changes to
java.awt.AWTEventMulticaster:public static WindowStateListener add(WindowStateListener a, WindowStateListener b) public static WindowStateListener remove(WindowStateListener l, WindowStateListener oldl)The bugtraq report that corresponds to this change is: 4077991.
Previously, dynamic window resizing wasn't supported on all platforms. For example, on Windows NT, with solid resize on, resizing a window recalculated the layout only when the drag was finished. This has been fixed in this release with the addition of the new desktop property
awt.dynamicLayoutSupported. When dynamic layout is enabled, aContainercontinually lays out its components as it resizes. If disabled, the layout will be validated after resizing has finished.API changes to
java.awt.Toolkit.public void setDynamicLayout(boolean dynamic) protected boolean isDynamicLayoutSet() public boolean isDynamicLayoutActive()Access to Component Listener Lists
The bugtraq report that corresponds to this change is: 4290704.
Previously all of the state in an AWT component that could be written could also be read. For example, there are no write-only properties in the component API. Event listeners were a notable exception. AWT event listeners are managed according to the JavaBeansTM conventions with a pair of methods:
addXXXListenerandremoveXXXListenerfor a listener that implements theXXXEventListenerinterface.No access was provided to the listener lists themselves. The fields that contain the listener lists are package private and no method was provided that returns the contents of a listener list. This has caused some problems for Swing and other AWT clients.
To mitigate the problem in the Java 2 SDK, v1.3 release, we added a
getListenersmethod toComponentand to the Swing classes that defined listener lists. ThegetListenersmethod uses a class to specify a particular listener list. For example to get all of the listeners added withaddFocusListener, one would write:getListeners(FocusListener.class).This particular approach to exposing listener lists was taken to minimize the overall change to the AWT/Swing public API. It was not intended to be a convention for all JavaBeans and it did not handle
PropertyChangeListeners - which can be added to a single property, as inaddPropertyChangeListener("myProperty", myListener). For this release, we have designed a more complete solution to accessing event listeners. The two conceptual changes are:
- The addition of a
getFooListenersmethod to the add/remove convention in AWT and Swing classes.- Support for
PropertyChangeListeners andVetoableChangeListeners, including those which listen to a single property, using the newjava.util.EventListenerProxyclass.There is a new
java.awt.event.AWTEventListenerProxyclass.API Changes to
java.awt.Toolkit:public PropertyChangeListener[] getPropertyChangeListeners() public synchronized PropertyChangeListener[] getPropertyChangeListeners(String propertyName) public AWTEventListener[] getAWTEventListeners() public AWTEventListener[] getAWTEventListeners(long eventMask)The bugtraq reports that corresponds to this change are: 4407057 and 4426750.
In the Solaris and Linux releases of Java 2 Standard Edition, SDK 1.3, several of the AWT heavyweight
Components exhibited default drag behavior via the middle mouse button, even if the application did not identify theseComponentsasDragSources via thejava.awt.dnd API. TheseComponents were implemented using Motif peers, and Motif provides middle button drag behavior for these peers by default.Because of the design of the AWT, and because of bugs in the Motif library, this default behavior has been the source of numerous stability problems. Rather than continue to risk the stability of AWT and Drag & Drop for a niche feature, we have chosen to disable this feature explicitly in our implementations.
Developers can still identify these
Components asDragSources in their applications using thejava.awt.dnd API. This is both functional and supported. This approach is superior to relying upon default Motif behavior in any case, because it enables drag support for theseComponents on all platforms, not just Solaris and Linux.64-Bit Compliance on Solaris Machines
Inconsistent DLLs WarningThe bugtraq report that corresponds to this change is: 4295833.
64-bit Solaris applications use 64 bits to address memory instead of 32. This allows larger applications by providing a much larger virtual memory space. For this release, AWT has been brought up to 64-bit compliance. For more information, see here.
Removal of the Drawing Surface APIThe bugtraq report that corresponds to this change is: 4414004.
If you have installed English VC++ 6.0 onto a machine that also has Asian Windows NT installed, you may encounter strange artifacts when rendering Asian text in the
TextAreacomponent. You may also see this problem if you have installed Microsoft Exchange or Microsoft Office 97 onto a machine running Asian Windows NT 4.0. Although this problem was reported on the Japanese version of Windows NT, it will probably occur on other non-Latin versions of NT as well, such as Chinese or Korean.The problem was caused when the installation of those programs replaced the Asian Riched32.dll with the English version. The problem can be corrected by replacing Riched32.dll with the Asian version.
Window Centering API Required for Multiscreen SupportThe bugtraq report that corresponds to this change is: 4293646.
The
sun.awt.DrawingSurfaceAPI has been removed. It was never made public, but some developers have been using it. The functionality has been replaced by the JAWT. For more information, see the AWT Native Interface description.New InputEvent Key ModifiersThe bugtraq report that corresponds to this change is: 4463949.
Xinerama-aware applications running on multi-headed systems have caused problems which have resulted in a variety of bug reports. Some multi-headed environments use monitors with little or no borders, which can be butted up against one another such that the resulting effect is one mammoth display. In this case, a "properly" centered window may span multiple screens. Other multi-headed environments use regular CRT monitors, with several inches of packaging between the actual display areas. In this case, a window spanning multiple screens produces a disconcerting effect, especially if the window cannot be dragged onto one monitor or the other (the Solaris login screen, for example). In short there was no way to tell where to center a window in a Xinerama environment.
To address this problem, the X group has added API which allows Xinerama users to specify where they want "centered" windows to be centered, and allows developers of Xinerama-aware applications to code accordingly.
Prior to this release, the way to center a window has been to center it within the bounds of the default
GraphicsDevice, like this:bounds = getDefaultScreenDevice().getDefaultConfiguration().getBounds(); frame.setLocation(bounds / 2 - size of window / 2);This code would center the windows "correctly" on Xinerama systems where windows should be centered to the entire Xinerama coordinate space.As of this release, post 4356756-fix JDKs will center windows "correctly" on Xinerama systems where windows should be centered within the first display.
To accomplish this, the
getCenterPointmethod has been added toGraphicsEnvironment.This method works as follows on various platforms:
- Microsoft Windows/Macintosh:
These platforms include all monitors in a single virtual coordinate space. However, there is one "primary" display (on Microsoft Windows the primary display contains the task bar, on the Mac, the menubar). Here,getCenterPointreturns the coordinates of the center of the primary display.- X-Window, non-Xinerama
Each display has its own coordinate system; the upper-left corner of every display is 0.0. Again, there is a "first" display. Here,getCenterPointreturns the center point of the primary display.- X-Window, Xinerama
All monitors share a single virtual coordinate space, as on Microsoft Windows. However, it is possible for the user to specify through X resources where windows should be centered. If these resources are set,getCenterPointreflects their value. Otherwise, it returns the point at the center of the virtual coordinate space. (In practice, this will almost always be set - CDE sets it by default.)As of JDK 1.4, the correct code for centering is:
frame.setLocation(getCenterPoint() - size of window / 2);The other method added to
GraphicsEnvironmentisgetMaximumWindowBounds. BothgetCenterPointandgetMaximumWindowBoundsthrow aHeadlessExceptionwhen in Headless mode.Change in Drop Down Behavior for Choice MenusThe bugtraq reports that corresponds to this change are: 4387938 and 4421515.
Previously, the
InputEventmodifiers had the same values for keyboard and mouse buttons. In certain situations there was no way to distinguish which one was pressed or when more than one was held simultaneously. These situations included cases when more than one mouse button was down at the same time, or when a modifier key was used to modify a mouse event.To address this deficiency, the following constants were added to
InputEvent:
SHIFT_DOWN_MASKCTRL_DOWN_MASKMETA_DOWN_MASKALT_DOWN_MASKALT_GRAPH_DOWN_MASKBUTTON1_DOWN_MASKBUTTON2_DOWN_MASKBUTTON3_DOWN_MASKThe following methods were added to
InputEvent:The class spec for
MouseEventwas updated. The following constants were also added toMouseEvent:These methods in
MouseEventwere added:
MouseEvent(Component source, int id, long when, int modifiers, int x, int y, int clickCount, boolean popupTrigger, int button)getButtongetMouseModifiersText
DragSourceDragEventhas the new methodgetGestureModifiersEx.Choice Component Now Obeys Layout Manager ConstraintsThe bugtraq report that corresponds to this change is: 4462677.
The
Choicedrop down menu behavior has changed from JDK 1.3.1 to 1.4. In 1.3.1, you could click anywhere on the choice bar and the menu would drop down. In 1.4, you must click on the arrow selector on the right hand side of theChoicebar. Clicking anywhere else on theChoicebar has no effect. Also, the symbol on theChoicebar has changed from a bar to an arrow/bar combination. Finally, if the drop down menu extends outside of the parent, when clicking on that area, the application underneath is brought to the foreground. This happens on Solaris, not Windows.Deprecated Focus MethodsThe bugtraq report that corresponds to this change is: 4288285.
In releases prior to 1.4, the AWT
Choicewidget sometimes ignored the size that the layout manager told it to be. As of this release, it now obeys the layout manager constraints.ActionEvents (and Other Events) Need TimestampsThe bugtraq report that corresponds to this change is: 4476300.
The new focus subsystem, introduced in this release, introduced a new architecture and a new terminology for handling keyboard focus in sophisticated AWT and Swing applications. Prior to this project, many of the focus-related APIs were inconsistent in usage and termonology, were improperly documented, and led to poorly designed UIs. Now that the new architecture is in place, the most egregious of these APIs has been deprecated.
The following constants and methods have been deprecated:
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)The bugtraq report that corresponds to this change is: 4434193.
The new focus architecture includes a type-ahead mechanism that ensures that subsequent
KeyEvents that follow aKeyEventthat initiates a focus transfer are not delivered until the transfer is completed. The design for this feature is based on the UTC timestamps of the various events. Events with timestamps later than that of the initiating event are enqueued pending resolution of the transfer; events with earlier timestamps are not.To implement this feature, the focus code keeps track of the timestamp of the event currently being handled. If a focus change is initiated during this handling, the timestamp is available for use. However, if the current event does not have a timestamp, then the current system time is used. This time is usually too far ahead of the time that the event actually occurred to be of any real use. As a result, the type-ahead mechanism fails, and
KeyEvents are delivered before the focus transfer is completed.The most common case where we encountered this problem was with
ActionEvents.ActionEvents are high-level, semantic events generated in response to underlyingInputEvents. While theInputEvents had timestamps associated with them, theActionEvents did not. TheActionEventAPI has therefore been expanded to accomodate a timestamp and the implementation has been updated so that anActionEvent's timestamp is equal to that of its underlyingInputEvent.The following methods have been added to
ActionEvent:The following
ActionEventmethods were modified:
ActionEvent(Object source, int id, String command)ActionEvent(Object source, int id, String command, int modifiers)The
getWhenmethod was added toInvocationEvent.The
InvocationEventconstructorsInvocationEvent(Object, Runnable)andInvocationEvent(Object, Runnable, Object, boolean)were modified.A new constructor
InputMethodEvent(Component, int, long, AttributedCharacterIterator, int, TextHitInfo, TextHitInfo)was added toInputMethodEvent, as well as thegetWhenmethod.The following
InputMethodEventconstructors have been modified:
InputMethodEvent(Component, int, AttributedCharacterIterator, int, TextHitInfo, TextHitInfo)InputMethodEvent(Component, int, TextHitInfo, TextHitInfo).Finally, the following methods were added to
EventQueue:
Copyright © 1993, 2010, Oracle and/or its affiliates. All rights reserved. Please send comments using this Feedback page. |
Java Technology |