Here are the incompatible AWT changes:
requestFocus method.
For example,
your implementation of the mouseClicked method
in the MouseListener for a custom component
should invoke the requestFocus method
on the component.
java.awt.peer package
have been removed in 1.1:
java.awt.peer.ComponentPeer:
public abstract boolean handleEvent(java.awt.Event);
public abstract void nextFocus();
java.awt.peer.ScrollbarPeer:
public abstract void setValue(int);
java.awt.peer.FramePeer:
public abstract void setCursor(int);
java.awt.peer package
is always subject to change
because the peer classes aren't intended
to be called directly by developers.
IllegalArgumentException.
Graphics drawPolygon method
used to draw unclosed polygons if the end point
wasn't the same as the start point.
In 1.1, drawPolygon automatically closes the polygon.
If you want to draw an unclosed polygon,
you can use the new drawPolyline method instead.
Color class now check
the range of the parameters passed in,
and throw an IllegalArgumentException
if out-of-range values are encountered.
Dialog constructor
now results in an IllegalArgumentException.
nextFocus
has been removed from the
java.awt.peer.ComponentPeer
interface.
This does not affect applications or applets,
since the peer interfaces are private interfaces
between the AWT and its implementations.
CheckBoxMenuItem class, the object argument
of the action() method has changed. In the 1.02
release the object argument was the label of the checkbox menu item, but
in the 1.1 release the object argument is the state of the
checkbox menu item.
handleEvent method
which is not
coded properly to handle these new events, you may see changes in the
way your program runs. For example, if you had the following fragment
in the handleEvent method of a Frame:
if (event.id == Event.GOT_FOCUS) {
// do something...
}
This block will now be called when components within the Frame
(such as buttons) get the focus. If the block isn't designed to handle
this case, then your program may not run as it did in 1.0.2.
In the new synchronization model, the structure and layout of
components inside containers is guarded by a single AWT-wide lock,
using an object called Component.LOCK, declared as follows in
the Component class:
public static final Object LOCK = new Object();
For example, Container.validate,
Container.add,
and Container.remove
all contain synchronized blocks
that use Component.LOCK.
Setter methods for individual component state, such as
Component.setEnabled or Button.setLabel,
are synchronized on the
instance itself. Getter methods are generally not synchronized, but
they are semi-guarded by the copy-to-stack strategy: a thread-local
copy of shared data is made and then used in the method.
Code that uses the AWT should be carefully scrutinized for uniform locking
order if it acquires locks of its own while overriding an AWT method
invoked in a synchronized context. For example, if you acquire your
own locks in your layout code, you have to be aware that this code is
being called with the Component.LOCK lock already held.
If your code
in another thread holds your lock
and then tries to invoke validate,
your program can deadlock. When you identify cases like this, you
should rewrite your code wherever possible to ensure a uniform locking
order. This order is usually client lock first,
then Component.LOCK.