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

Phil Race philip.race at oracle.com
Mon Feb 16 22:45:02 UTC 2015


Hi,

Regardless of any changes to the methods using peers, in a modular JDK 
nothing
else inside the module java.desktop is accessible to external code anyway.

The module system has preventing access to module (JDK) internals
by code outside that module as a core goal.

So (eg!) if you rely on SunToolkit or SunFontManager for a porting 
layer, then
you are going to have to be part of the desktop module in order to use them,

Once you are inside there then the peer packages are accessible again too.

-phil.

On 2/16/15 9:54 AM, Roman Kennke wrote:
> Am Montag, den 16.02.2015 um 09:05 +0100 schrieb 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.
> As far as I understand it, it probably wouldn't. It would only affect
> applications that somehow use the Toolkit.createFluffPeer() methods, for
> whatever reason. It should not break peer implementations. At least not
> internal ones.
>
>> 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.
> I would welcome this. Chasing changing internal APIs ain't no fun. And
> if the peer interfaces really are not available external libs, then
> yeah, Cacio would need to be part of the bootclasspath (whatever that
> means in module land).
>
>> Perhaps the peers should be more abstracted away, rather then
>> completely removed.
> I don't think the idea is to remove the peers altogether.
>
> Regards,
> Roman
>
>



More information about the awt-dev mailing list