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
