<AWT Dev> Removing all methods that use the AWT peer types in JDK 9

[Mario Torre]

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 <options> <classes...>
> where <classes> 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/