AWT Enhancements in the JavaTM 2 Platform Standard Edition 5.0
Window Bugfixes and Enhancements
DnD and Data Transfer Bugfixes and Enhancements
Known Bugs and Issues
4615479: XToolkit on Solaris and LinuxIn this release, AWT has been reimplemented on the Solaris and Linux platforms. It is possible to force the Motif toolkit on Linux or XAWT on Solaris. This is done either by setting the
AWT_TOOLKITvariable or using the
-Dawt.toolkitcommand line parameter. The value for XAWT is
sun.awt.X11.XToolkitand the value for Motif is
sun.awt.motif.MToolkit. For more information, see the XToolkit on Solaris/Linux note.
4638443: XDnD SupportAs of this release, the XDnD Protocol support has been implemented as part of the data transfer system. Prior to this release, only the Motif DnD protocol was supported on X11.
4009555: Obtaining the mouse location on the desktopAPI has been added to obtain the mouse location on the desktop. The new PointerInfo class describes the pointer coordinates and the associated
GraphicsDeviceobject at the moment the
PointerInfoinstance is created.
PointerInfohas the following methods:
The new MouseInfo class has information about the current location of the mouse pointer.
MouseInfohas two methods:
Other new methods:
4632143: Window, Frame or Dialog Always on TopNew API has been added to ensure that a particular
Dialogis always on top of the desktop. This is useful when implementing certain GUI elements, such as tool boxes, notification or information applets, and other desktop-enhancing features. The new and modified API includes:
- addPropertyChangeListener(String, PropertyChangeListener)The
addXXXmethods have been modified to support setting a property change listener on the window's
- java.awt.PermissionThe new
setWindowAlwaysOnToppermission has been added.
Depending on the system setup, always-on-top Windows, Frames or Dialogs may not be supported. They are supported on Microsoft Windows, Linux and Solaris running GNOME2/Metacity, as well as Linux running KDE/kwin. They are not supported on Solaris running CDE/dtwm. It is possible that always-on-top windows do not work on Linux or Solaris running session and window managers other than those mentioned above.
4102292: New API to Specify Default Window Location by PlatformTwo new methods and one new property allow the user to specify the default location for a new
Window, appropriate to the platform. This is especially important for X11. The new api includes:
Note that the
- Window.isLocationByPlatform (a property)
locationByPlatformproperty must be set to true for the underlying window manager to tile the window according to its own logic. Otherwise, AWT won't know whether the window was put at 0,0 intentionally or was just unspecified and the window will be placed at the upper-left-hand corner of the screen.
4101435: Window/Dialog/Frame.setLocation doesn't always work as expectedThe location and size of Windows, Dialogs and Frames, is under the control of the desktop's window management system, not the application or the toolkit. The window manager is free to ignore or modify a window placement request. Therefore, when calling Window.setLocation(x, y), you can't rely on the Window being moved to location (x, y). The same situation exists for Window.setSize and Window.setBounds. The Window documentation has been clarified to explain this.
4401846: New _JAVA_AWT_WM_STATIC_GRAVITY Environment VariableCertain window managers position AWT windows incorrectly. For example, a window that is requested to be moved to (0,0) will, under some window managers, be positioned so that the window's title and left border are off-screen. This is because there are two schools of window managers that disagree on the interpretation of the ICCCM specification for the ConfigureRequest requests that X11 programs make to position their windows.
To address this issue, the
_JAVA_AWT_VM_STATIC_GRAVITYenvironment variable has been added so that a power user can indicate that his window manager implements the StaticGravity behavior.
4378091: New DropTarget.getTransferable methodThe new java.awt.dnd.DropTargetDragEvent.getTransferable method enables the drop target to access transfer data during a drag operation.
This also fixes bug 4248542: DropTargetListener can't access the transferable in dragOver and dragEnter.
4259272: Notification of Clipboard contents changes is now supportedPreviously, the Java clipboard API didn't allow an efficient way to track changes to the set of DataFlavors available on the clipboard or notify interested parties about those changes. API has been added for this purpose:
4287795: New methods for querying information in a ClipboardThree new methods have been added:
4790833: Memory Usage No Longer Shoots Up using Clipboard.getContentsPrior to this release,
Clipboard.getContentsfetched clipboard data in all provided formats for which a mapping to the corresponding data flavor in the default flavor map exists. If there were a lot of formats and the data were large, a lot of memory was consumed with the fetched data in different formats. Thanks to the new methods introduced with bug fix 4287795, this problem has been fixed.
4415175: New API to Globally Change the DnD Gesture Motion ThresholdThe drag motion gesture threshold represents the number of pixels the cursor is dragged before the data transfer system initiates a drag operation. Prior to this release, this was hard-coded to 5 pixels. As of release 5.0, there is support for picking up the desktop properties for drag sensitivity and mapping it to the threshold, and new API that allows users to get and change this threshold. The new API includes:
4712068: DnD Usability Issue for Dragging TextPrior to this release, the hotspot of the drop icons used on X platforms was located at the middle of the icon. When dragging text, the text cursor moves to indicate the current drop location, but this was obscurbed by the drop icon itself. For this release, the drop cursors used on X platforms have been changed to point to the upper-left corner of the drop icon. The corresponding hotspots have been changed accordingly.
4191708: Clarification in spec for several java.awt.dnd.DropTarget methodsThe doc has been clarified with respect to passing in a null parameter for the following
4819437: DragSourceListener.dragExit is now called in a consistent wayThe class specification for the DragSourceAdapter and DragSourceAdapter classes, and the documentation for the DragSourceAdapter.dragExit and DragSourceListener.dragExit methods have been updated to clarify the notion that the drop site is associated with the previous call to
4654688: SystemFlavorMap Methods Now Consistent with DocumentationThe
SystemFlavorMapclass is used to store mappings between native formats and Java data flavors in order to support data transfer between native and Java applications. The documentation for the SystemFlavorMap.getNativesForFlavor(DataFlavor) method has been clarified to say that a
DataFlavor(or a native format) is known if and only if it has at least one static mapping associated with it.
4123385: Documentation Clarification for Drag Source Events Constructors ConstructorsThe documentation has been clarified with respect to passing in invalid parameters for the following constructors of drag source events:
GridBagLayout BugfixesGridBagLayout: Several bugfixes have been implemented for GridBagLayout. Note that two of these bugs listed apply to the documentation only. The most significant bugfixes include:
4254022: More than 512 horizontal or vertical components are now possible in a GridBagLayoutPreviously, GridBagLayout had been implemented with a hard-coded width and height limit of 512. This is now allocated dynamically and the MAXGRIDSIZE constant is no longer used.
4532201: GridBagLayout.lookupConstraints doc is clarifiedDocumentation was added to clarify what happens when the specified Component is not in the grid bag layout.
4618355: Doc for GridBagLayout.gridwidth/gridheight is clarifiedThe class spec for GridBagLayout.gridwidth/gridheight was confusing in its description of REMAINDER and RELATIVE. This has been corrected.
FlowLayout BugfixesFlowLayout: Several documentation bugs have been fixed for FlowLayout
4586806: FlowLayout spec is corrected regarding alignmentPreviously, the class spec stated that components are centered on the line. Actually, the
alignproperty determines how the components are laid out. The doc has been corrected.
4881919: FlowLayout class spec no longer implies that components are always left to rightThe FlowLayout class spec was written before the ability to go right to left was added. Therefore it assumed that left to right was the only possible orientation. The doc has been corrected.
4587456: Corrected spec for FlowLayout constructorPreviously, the doc for the FlowLayout constructor neglected to mention that the hgap and vap were applied to the spacing between the components and the container border as well as between the components. The documentation has been corrected.
4172932: New methods to get constraints for children in BorderLayoutThree public methods have been added to
BorderLayout, one to get the constraints for a component, and two different ways to get the component for a given constraint (one takes component orientation into account and the other doesn't). The new methods are:
4515041: Clarified spec for GridLayout.layoutContainer regarding vgap and hgap paramsPreviously, the spec for layoutContainer stated that the vgap and hgap was added between each cell and between the first/last cell and the border. In reality, the gaps are applied between the components only. This has been corrected in the doc.
4533021: New API to Change the Z-ordering of ChildrenNew API has been added to specify the z-ordering of children in a
Container. The two new
4370733: AWTKeyStroke.getAWTKeyStroke(String) and toString are now symmetricPreviously it was not possible to take the output from
AWTKeyStroke.toStringand pass it to the
getAWTKeyStrokemethod. This has been changed so the methods
4341785: Clarify spec for several List methodsThe spec for the following
Listmethods has been clarified to state that unspecified behavior results when the range is out of bounds:
4368570: Clarify List spec regarding behavior of clicking on a selected itemPreviously, the class spec for List stated that clicking on an unselected item selects it and clicking on a selected item de-selects it. This is true only if the list is in multiple-selection mode. In single-selection mode, any click on a list's item selects the clicked item. The spec has been clarified.
4082708: Clarified spec for the ContainerEvent.getContainer methodThe ContainerEvent.getContainer method assumes that
sourceis of type
Container. Previously, it casted the source to type
Containerwithout first checking which could result in ClassCastException. The method has been changed to return a value of null if the source isn't a
4620715: New KeyEvent codes for two standard Microsoft Windows keys.Two keys on a standard Microsoft Windows keyboard don't have Java keycodes — the windows key and the context menu key. This impedes the ability to meet 508 requirements. Therefore, the
java.awt.event.KeyEvent.VK_CONTEXT_MENUkeycodes have been added.
4829063: Scrollbar now specifies that Scrollbar thumb may not be visiblePreviously, the doc for Scrollbar.getVisibleAmount and setVisibleAmount did not say that sometimes the thumb might not be visible or accurately describe what the scrollbar's range is used for. The specification has been cleaned up. This is a doc-only change.
4840172: Behavior of KeyEvent.getKeyChar is clarifiedUse of KeyEvent.getKeyChar is explained in the KeyEvent class documentation, but the doc for the method itself was brief. The doc for getKeyChar has been improved for this release.
4233061: Clarify spec that ENTER doesn't fire an ActionEventThere is confusion among some developers that when the focus is on a
Button, pressing the ENTER key doesn't fire an
ActionEvent. This is correct behavior. The SPACE bar fires an
ActionEvent. The ActionEvent class specification was updated to clarify this fact.
4221123: New FileDialog constructorsThree new
FileDialogconstructors have been added that can specify a
Dialogas the owner:
4691481: Updated spec for Robot.createScreenCapturePreviously, the documentation for Robot.createScreenCapture didn't mention that the mouse cursor is not included in the captured image. This has always been true of Solaris, Linux, Windows and Mac OS X. The documentation has been updated to reflect this information.
4704042: New method for setting InsetsA single method to set Insets has been added: set(int, int, int, int).
4492739: Clarify InputEvent.ALT_MASK/BUTTON2_MASK and META_MASK/BUTTON3_MASK docThere is an overlap in the values for some of the InputEvent constants. This is confusing because when calling KeyEvent.getModifiersExText(int) and MouseEvent.getMouseEventModifiersText(int) the string returned for KeyEvent.BUTTON2_MASK is "Alt" and the string returned for KeyEvent.BUTTON3_MASK is "Meta". For this release, documentation was added to the InputEvent, KeyEvent and MouseEvent classes to clarify this.Here is a list of known problems you may encounter in release 5.0.
Metacity versioningWe recommend using the latest build of Metacity (which is currently 2.6.2). There were some bugs that occurred with versions prior to 2.4.34 (problems with programmatic iconification, and non-resizable frames, for example) that have since been fixed.
5051557: Applet focus incompatibilityWe have received reports that, in some applets, pressing a key on the keyboard doesn't have the expected result. This usually happens because the applet doesn't get the focus automatically when there are no child components in the applet. To ensure that such an applet works across all platforms, it is recommended that you request the focus at startup (via
requestFocus) and on mouse press. If you don't want the focus, call
5050387: JVM may crash when JOptionPane is invoked from drop()On Solaris/Linus running MToolKit, displaying a
dropmethod may cause the JVM to crash. This bug will be addressed in a future release.
Focus bugs when running appletsThere were focus-related bugs noticeable when running applets in Mozilla in release 1.4.2 and earlier. This includes:
To solve this problem, the client side of the XEmbed protocol was implemented:
- 4907493: Input focus not working with multiple applets
- 4902616: The characters of a text field can't delete when doing Java Plug-in test
- 4877530: Unable to input text into JTextField in 1.4.1_02
- 4806274: The requestFocus method doesn't bring focus to the component on Netscape 7 on Solaris
- 4816394: Can't input anything to SpreadSheet
- 4837794: Can't input charact to login AnswerCenter with Java applet
- 4902609: Tab key can't work when doing Java test case
However, the browser should support the server side of XEmbed in order for it to work. We recommend using the following browsers with Java:
- 4849238: Add XEmbed support to AWT
- 4907325: XEmbed should be implemented for the Motif toolkit
- On Linux, Mozilla community edition at least version 1.5 or higher.
- On Solaris, Sun Mozilla at least version 1.4 or higher.
Copyright © 1993, 2011, Oracle and/or its affiliates. All rights reserved.