AWT Enhancements in the Java 2 Platform Standard Edition 5.0
Major Changes
Window Bugfixes and Enhancements
DnD and Data Transfer Bugfixes and
Enhancements
Layout Bugfixes
Miscellaneous Bugfixes
Known Bugs and Issues
4615479: XToolkit on Solaris and Linux
In 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_TOOLKIT
variable or using the
-Dawt.toolkit
command line parameter. The value for
XAWT is
sun.awt.X11.XToolkit
and the value for Motif
is
sun.awt.motif.MToolkit
. For more information, see
the
XToolkit on Solaris/Linux
note.
As 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
desktop
API has been added to obtain the mouse location on the
desktop. The new
PointerInfo class
describes the pointer coordinates and the associated
GraphicsDevice
object at the moment the
PointerInfo
instance is created.
PointerInfo
has the following methods:
The new MouseInfo class has
information 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
is
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:
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
Platform
Two 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
locationByPlatform
property 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 expected
The 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
Variable
Certain 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_GRAVITY
environment variable has
been added so that a power user can indicate that his window
manager implements the StaticGravity behavior.
4378091: New DropTarget.getTransferable method
The 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 supported
Previously, 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
Clipboard
Three new methods have been added:
4790833: Memory Usage No Longer Shoots Up using
Clipboard.getContents
Prior to this release,
Clipboard.getContents
fetched 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 Threshold
The 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 Text
Prior 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 methods
The doc has been clarified with respect to passing in a
null parameter for the following
java.awt.dnd.DropTarget
methods:
4819437: DragSourceListener.dragExit is now called in a
consistent way
The 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
dragEnter
.
4654688: SystemFlavorMap Methods Now Consistent with
Documentation
The
SystemFlavorMap
class 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 Constructors
The documentation has been clarified with respect to
passing in invalid parameters for the following constructors of
drag 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 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 GridBagLayout
Previously, 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
clarified
Documentation was added to clarify what happens when
the specified Component is not in the grid bag layout.
4618355: Doc for GridBagLayout.gridwidth/gridheight is
clarified
The class spec for GridBagLayout.gridwidth/gridheight
was confusing in its description of REMAINDER and RELATIVE. This
has been corrected.
FlowLayout Bugfixes
FlowLayout: Several documentation bugs have been
fixed for FlowLayout
4586806: FlowLayout spec is corrected regarding
alignment
Previously, the class spec stated that components are
centered on the line. Actually, the
align
property
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 right
The 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 constructor
Previously, 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
BorderLayout
Three 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 params
Previously, 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
Children
New API has been added to specify the z-ordering of
children in a
Container
. The two new
Container
methods include:
4370733: AWTKeyStroke.getAWTKeyStroke(String) and
toString 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 the
methods
4341785: Clarify spec for several List methods
The spec for the following
List
methods
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 item
Previously, 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 method
The
ContainerEvent.getContainer method assumes that
source
is of type
Container
. Previously,
it casted the source to type
Container
without first
checking which could result in ClassCastException. The method has
been changed to return a value of null if the source isn't a
Container
.
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_WINDOWS
and
java.awt.event.KeyEvent.VK_CONTEXT_MENU
keycodes have
been added.
4829063: Scrollbar now specifies that Scrollbar thumb
may not be visible
Previously, 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
clarified
Use 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
ActionEvent
There 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 constructors
Three new
FileDialog
constructors have
been added that can specify a
Dialog
as the owner:
4691481: Updated spec for Robot.createScreenCapture
Previously, 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 Insets
A 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 doc
There 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 versioning
We 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 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 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
setFocusable(false)
.
5050387: JVM may crash when JOptionPane is invoked from
drop()
On Solaris/Linus running MToolKit, displaying a
JOptionpane
from the
drop
method may
cause the JVM to crash. This bug will be addressed in a future
release.
Focus bugs when running applets
There were focus-related bugs noticeable when running
applets in Mozilla in release 1.4.2 and earlier. This includes:
-
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
To solve this problem, the client side of the XEmbed protocol was
implemented:
- 4849238: Add XEmbed support to AWT
- 4907325: XEmbed should be implemented for the Motif
toolkit
However, the browser should support the server side of XEmbed in
order for it to work. We recommend using the following browsers
with Java:
- On Linux, Mozilla community edition at least version 1.5 or
higher.
- On Solaris, Sun Mozilla at least version 1.4 or higher.