AWT Enhancements in the Java 2 Platform Standard Edition 5.0
Major ChangesWindow Bugfixes and EnhancementsDnD and Data Transfer Bugfixes andEnhancementsLayout BugfixesMiscellaneous BugfixesKnown Bugs and Issues
4615479: XToolkit on Solaris and Linux
In this release, AWT has been reimplemented on theSolaris and Linux platforms. It is possible to force the Motiftoolkit on Linux or XAWT on Solaris. This is done either by settingthe
AWT_TOOLKIT variable or using the
-Dawt.toolkit command line parameter. The value forXAWT is
sun.awt.X11.XToolkit and the value for Motifis
sun.awt.motif.MToolkit. For more information, seethe
XToolkit on Solaris/Linuxnote.
As of this release, the
XDnD Protocol supporthas been implemented as part of the data transfer system. Prior tothis release, only the Motif DnD protocol was supported onX11.
4009555: Obtaining the mouse location on thedesktop
API has been added to obtain the mouse location on thedesktop. The new
PointerInfo classdescribes the pointer coordinates and the associated
GraphicsDevice object at the moment the
PointerInfo instance is created.
PointerInfo has the following methods:
The newMouseInfo class hasinformation about the current location of the mouse pointer.MouseInfo has two methods:
Other new methods:
4632143: Window, Frame or Dialog Always on Top
New API has been added to ensure that a particular
Window,
Frame or
Dialog isalways on top of the desktop. This is useful when implementingcertain GUI elements, such as tool boxes, notification orinformation applets, and other desktop-enhancing features. The newand modified API includes:
Depending on the system setup, always-on-top Windows, Frames orDialogs may not be supported. They are supported on MicrosoftWindows, Linux and Solaris running GNOME2/Metacity, as well asLinux running KDE/kwin. They are not supported on Solaris runningCDE/dtwm. It is possible that always-on-top windows do not work onLinux or Solaris running session and window managers other thanthose mentioned above.
4102292: New API to Specify Default Window Location byPlatform
Two new methods and one new property allow the user tospecify the default location for a new
Window,appropriate to the platform. This is especially important for X11.The new api includes:
Note that the
locationByPlatform property must be setto true for the underlying window manager to tile the windowaccording to its own logic. Otherwise, AWT won't know whether thewindow was put at 0,0 intentionally or was just unspecified and thewindow will be placed at the upper-left-hand corner of thescreen.
4101435: Window/Dialog/Frame.setLocation doesn't alwayswork as expected
The location and size of Windows, Dialogs and Frames,is under the control of the desktop's window management system, notthe application or the toolkit. The window manager is free toignore or modify a window placement request. Therefore, whencalling Window.setLocation(x, y), you can't rely on the Windowbeing moved to location (x, y). The same situation exists forWindow.setSize and Window.setBounds. The Window documentation hasbeen clarified to explain this.
4401846: New _JAVA_AWT_WM_STATIC_GRAVITY EnvironmentVariable
Certain window managers position AWT windowsincorrectly. For example, a window that is requested to be moved to(0,0) will, under some window managers, be positioned so that thewindow's title and left border are off-screen. This is becausethere are two schools of window managers that disagree on theinterpretation of the ICCCM specification for the ConfigureRequestrequests that X11 programs make to position their windows.
To address this issue, the_JAVA_AWT_VM_STATIC_GRAVITY environment variable hasbeen added so that a power user can indicate that his windowmanager implements the StaticGravity behavior.
4378091: New DropTarget.getTransferable method
The new
java.awt.dnd.DropTargetDragEvent.getTransferable method enablesthe drop target to access transfer data during a drag operation.
This also fixes bug4248542: DropTargetListener can't access thetransferable in dragOver and dragEnter.
4259272: Notification of Clipboard contents changes isnow supported
Previously, the Java clipboard API didn't allow anefficient way to track changes to the set of DataFlavors availableon the clipboard or notify interested parties about those changes.API has been added for this purpose:
4287795: New methods for querying information in aClipboard
Three new methods have been added:
4790833: Memory Usage No Longer Shoots Up usingClipboard.getContents
Prior to this release,
Clipboard.getContents fetched clipboard data in allprovided formats for which a mapping to the corresponding dataflavor in the default flavor map exists. If there were a lot offormats and the data were large, a lot of memory was consumed withthe fetched data in different formats. Thanks to the new methodsintroduced with bug fix
4287795, this problem has been fixed.
4415175: New API to Globally Change the DnD GestureMotion Threshold
The drag motion gesture threshold represents the numberof pixels the cursor is dragged before the data transfer systeminitiates a drag operation. Prior to this release, this washard-coded to 5 pixels. As of release 5.0, there is support forpicking up the desktop properties for drag sensitivity and mappingit to the threshold, and new API that allows users to get andchange this threshold. The new API includes:
4712068: DnD Usability Issue for Dragging Text
Prior to this release, the hotspot of the drop iconsused on X platforms was located at the middle of the icon. Whendragging text, the text cursor moves to indicate the current droplocation, but this was obscurbed by the drop icon itself. For thisrelease, the drop cursors used on X platforms have been changed topoint to the upper-left corner of the drop icon. The correspondinghotspots have been changed accordingly.
4191708: Clarification in spec for severaljava.awt.dnd.DropTarget methods
The doc has been clarified with respect to passing in anull parameter for the following
java.awt.dnd.DropTarget methods:
4819437: DragSourceListener.dragExit is now called in aconsistent way
The class specification for the
DragSourceAdapterand
DragSourceAdapterclasses, and the documentation for the
DragSourceAdapter.dragExit and
DragSourceListener.dragExit methods have been updated toclarify the notion that the drop site is associated with theprevious call to
dragEnter.
4654688: SystemFlavorMap Methods Now Consistent withDocumentation
The
SystemFlavorMap class is used to storemappings between native formats and Java data flavors in order tosupport data transfer between native and Java applications. Thedocumentation for the
SystemFlavorMap.getNativesForFlavor(DataFlavor) method has beenclarified to say that a
DataFlavor (or a nativeformat) is known if and only if it has at least one static mappingassociated with it.
4123385: Documentation Clarification for Drag SourceEvents Constructors Constructors
The documentation has been clarified with respect topassing in invalid parameters for the following constructors ofdrag source events:
- DragSourceDragEvent(DragSourceContext, int int, int)
- DragSourceDragEvent(DragSourceContext, int int, int, int,int)
- DragSourceDropEvent(DragSourceContext)
- DragSourceDropEvent(DragSourceContext, int, boolean)
- DragSourceDropEvent(DragSourceContext, int, boolean, int,int)
GridBagLayout Bugfixes
GridBagLayout: Several bugfixes have beenimplemented for GridBagLayout. Note that two of these bugs listedapply to the documentation only. The most significant bugfixesinclude:
4254022: More than 512 horizontal or vertical componentsare now possible in a GridBagLayout
Previously, GridBagLayout had been implemented with ahard-coded width and height limit of 512. This is now allocateddynamically and the MAXGRIDSIZE constant is no longerused.
4532201: GridBagLayout.lookupConstraints doc isclarified
Documentation was added to clarify what happens whenthe specified Component is not in the grid bag layout.
4618355: Doc for GridBagLayout.gridwidth/gridheight isclarified
The class spec for GridBagLayout.gridwidth/gridheightwas confusing in its description of REMAINDER and RELATIVE. Thishas been corrected.
FlowLayout Bugfixes
FlowLayout: Several documentation bugs have beenfixed for FlowLayout
4586806: FlowLayout spec is corrected regardingalignment
Previously, the class spec stated that components arecentered on the line. Actually, the
align propertydetermines how the components are laid out. The doc has beencorrected.
4881919: FlowLayout class spec no longer implies thatcomponents are always left to right
The FlowLayout class spec was written before theability to go right to left was added. Therefore it assumed thatleft to right was the only possible orientation. The doc has beencorrected.
4587456: Corrected spec for FlowLayout constructor
Previously, the doc for the FlowLayout constructorneglected to mention that the hgap and vap were applied to thespacing between the components and the container border as well asbetween the components. The documentation has beencorrected.
4172932: New methods to get constraints for children inBorderLayout
Three public methods have been added to
BorderLayout, one to get the constraints for acomponent, and two different ways to get the component for a givenconstraint (one takes component orientation into account and theother doesn't). The new methods are:
4515041: Clarified spec for GridLayout.layoutContainerregarding vgap and hgap params
Previously, the spec for layoutContainer stated thatthe vgap and hgap was added between each cell and between thefirst/last cell and the border. In reality, the gaps are appliedbetween the components only. This has been corrected in thedoc.
4533021: New API to Change the Z-ordering ofChildren
New API has been added to specify the z-ordering ofchildren in a
Container. The two new
Container methods include:
4370733: AWTKeyStroke.getAWTKeyStroke(String) andtoString are now symmetric
Previously it was not possible to take the output from
AWTKeyStroke.toString and pass it to the
getAWTKeyStroke method. This has been changed so themethods
4341785: Clarify spec for several List methods
The spec for the following
List methodshas been clarified to state that unspecified behavior results whenthe range is out of bounds:
4368570: Clarify List spec regarding behavior ofclicking on a selected item
Previously, the class spec for List stated thatclicking on an unselected item selects it and clicking on aselected item de-selects it. This is true only if the list is inmultiple-selection mode. In single-selection mode, any click on alist's item selects the clicked item. The spec has beenclarified.
4082708: Clarified spec for theContainerEvent.getContainer method
The
ContainerEvent.getContainer method assumes that
source is of type
Container. Previously,it casted the source to type
Container without firstchecking which could result in ClassCastException. The method hasbeen changed to return a value of null if the source isn't a
Container.
4620715: New KeyEvent codes for two standard MicrosoftWindows keys.
Two keys on a standard Microsoft Windows keyboard don'thave Java keycodes — the windows key and the context menu key. Thisimpedes the ability to meet 508 requirements. Therefore, the
java.awt.event.KeyEvent.VK_WINDOWS and
java.awt.event.KeyEvent.VK_CONTEXT_MENU keycodes havebeen added.
4829063: Scrollbar now specifies that Scrollbar thumbmay not be visible
Previously, the doc for Scrollbar.getVisibleAmount andsetVisibleAmount did not say that sometimes the thumb might not bevisible or accurately describe what the scrollbar's range is usedfor. The specification has been cleaned up. This is a doc-onlychange.
4840172: Behavior of KeyEvent.getKeyChar isclarified
Use of KeyEvent.getKeyChar is explained in the KeyEventclass documentation, but the doc for the method itself was brief.The doc for getKeyChar has been improved for thisrelease.
4233061: Clarify spec that ENTER doesn't fire anActionEvent
There is confusion among some developers that when thefocus is on a
Button, pressing the ENTER key doesn'tfire an
ActionEvent. This is correct behavior. TheSPACE bar fires an
ActionEvent. The
ActionEventclass specification was updated to clarify this fact.
4221123: New FileDialog constructors
Three new
FileDialog constructors havebeen added that can specify a
Dialog as the owner:
4691481: Updated spec for Robot.createScreenCapture
Previously, the documentation forRobot.createScreenCapture didn't mention that the mouse cursor isnot included in the captured image. This has always been true ofSolaris, Linux, Windows and Mac OS X. The documentation has beenupdated to reflect this information.
4704042: New method for setting Insets
A single method to set Insets has been added:
set(int, int, int, int).
4492739: Clarify InputEvent.ALT_MASK/BUTTON2_MASK andMETA_MASK/BUTTON3_MASK doc
There is an overlap in the values for some of theInputEvent constants. This is confusing because when callingKeyEvent.getModifiersExText(int) andMouseEvent.getMouseEventModifiersText(int) the string returned forKeyEvent.BUTTON2_MASK is "Alt" and the string returned forKeyEvent.BUTTON3_MASK is "Meta". For this release, documentationwas added to the InputEvent, KeyEvent and MouseEvent classes toclarify this.
Here is a list of known problems you may encounter inrelease 5.0.
Metacity versioning
We recommend using the latest build of Metacity (whichis currently 2.6.2). There were some bugs that occurred withversions prior to 2.4.34 (problems with programmatic iconification,and non-resizable frames, for example) that have since beenfixed.
5051557: Applet focus incompatibility
We 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 focusautomatically when there are no child components in the applet. Toensure that such an applet works across all platforms, it isrecommended that you request the focus at startup (via
requestFocus) and on mouse press. If you don't wantthe focus, call
setFocusable(false).
5050387: JVM may crash when JOptionPane is invoked fromdrop()
On Solaris/Linus running MToolKit, displaying a
JOptionpane from the
drop method maycause the JVM to crash. This bug will be addressed in a futurerelease.
Focus bugs when running applets
There were focus-related bugs noticeable when runningapplets in Mozilla in release 1.4.2 and earlier. This includes:
- 4907493: Input focus not working with multipleapplets
- 4902616: The characters of a text field can't deletewhen doing Java Plug-in test
- 4877530: Unable to input text into JTextField in1.4.1_02
- 4806274: The requestFocus method doesn't bring focus tothe component on Netscape 7 on Solaris
- 4816394: Can't input anything to SpreadSheet
- 4837794: Can't input charact to login AnswerCenter withJava applet
- 4902609: Tab key can't work when doing Java testcase
To solve this problem, the client side of the XEmbed protocol wasimplemented:
- 4849238: Add XEmbed support to AWT
- 4907325: XEmbed should be implemented for the Motiftoolkit
However, the browser should support the server side of XEmbed inorder for it to work. We recommend using the following browserswith Java:
- On Linux, Mozilla community edition at least version 1.5 orhigher.
- On Solaris, Sun Mozilla at least version 1.4 or higher.
Copyright © 1993, 2020, Oracleand/or its affiliates. All rights reserved.