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

Mario Torre neugens.limasoftware at gmail.com
Mon Feb 16 08:05:37 UTC 2015

Hi Phil,

While I welcome this, it also means it will make impossible to create custom ports of the AWT ports for *JDK9+. For one, it will break Caciocavallo for example.

Do you have any suggestion how we can deal with this?

For Cacio, we can try to merge the code in the JDK proper (long overdue anyway), but generic custom ports may be very hard to do. Perhaps the peers should be more abstracted away, rather then completely removed.

Cheers, Mario

2015-02-13 23:32 GMT+01:00 Phil Race <philip.race at oracle.com>:

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 <classes...> where can be a pathname to a .class file, a directory, a JAR file, or a fully-qualified class name

-- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards: http://endsoftpatents.org/

More information about the awt-dev mailing list