All methods that refer to types defined in the java.awt.peer and
java.awt.dnd.peer
packages (the "peer types") will be removed from the Java API in Java SE
9 .
https://bugs.openjdk.java.net/browse/JDK-8037739
Application code which calls any such method which accepts or returns a
type
defined in these packages will no longer link. This is a BINARY
incompatible change.
Why are we doing this ? Because we expect that the standard Java SE
modules (see
http://openjdk.java.net/jeps/200) will not export any internal packages
such as these peer
packages, therefore the peer types will be inaccessible even if we do
not remove them,
so we might as well bite the bullet.
This is probably an unprecedented change, since even though many of the
methods were
deprecated in JDK 1.1 in 1996 - when it was realised they should not be
used by applications,
no one has gone and actually removed them so applications and libraries
(jars you rely on)
have continued to use them despite 19 years of being warned.
The proposal to remove the packages is not being undertaken lightly and
we are concerned
about breaking applications but we don't seem to have many options here.
There's a fairly long list of createFoo() methods on Toolkit that return
a peer type and some methods in java.awt.dnd
that expose peer types and whilst they are used by some code and *all*
will disappear
we think there's one method that stands out that is more likely to
affect applications.
The cases we've examined almost all use java.awt.Component's method
java.awt.peer.ComponentPeer getPeer() and they use it mostly like this
where they don't appear to need to use the returned object :-
if (c.getPeer() != null) { .. }
We recommend replacing this code with:
if (c.isDisplayable()) { ... }
which has been available since JDK 1.1 and it does the same in a
supported manner.
Some other further usages have been to see if a component has a
LightweightPeer
For that since JDK 1.2 there has been
public boolean isLightweight() ;
One single isolated usage we found was :-
if ( (getPanel().getPeer() != null) &&
(getPanel().getPeer().getColorModel() != null) )
But this could be replaced with the JDK 1.0 API :-
public ColorModel getColorModel() { ... }
- the color model of the component comes from the peer if it has one.
So we think most code has a migration path away from the peer packages and
this is a heads-up to start that migration now.
If there's any unsolvable case you think we've missed let us know and maybe
there can be a supported alternative added.
If you don't know if you use these types (because you use 3rd party jars)
you can use the JDK 8 "jdeps" tool to find such dependencies :-
~/jdk1.8/bin/jdeps
Usage: jdeps <options> <classes...>
where <classes> can be a pathname to a .class file, a directory, a JAR
file, or a fully-qualified class name
