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:
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:
The new setWindowAlwaysOnTop permission
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
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.
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:
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:
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:
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:
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.
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
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.
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.
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.
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