Removing all methods that use the AWT peer types in JDK 9 (original) (raw)

Phil Race philip.race at oracle.com
Fri Feb 13 22:32:19 UTC 2015

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() { ...  }

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 <classes...> where can be a pathname to a .class file, a directory, a JAR file, or a fully-qualified class name -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20150213/bc2640f9/attachment.html>

More information about the awt-dev mailing list