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

[Mario Torre]

On Mon, 2015-02-16 at 18:54 +0100, 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).

Yes, on the other end this cost doesn't go away, somebody will still
need to update the toolkits when the peers move stuff around.

Merging Cacio with the JDK doesn't automatically means we're finished,
and, in fact, there are more problems to solve, like the need to access
the TCK and fix the compatibility issues, the requirement of being on
call for quickly updates, the need for more direct collaboration from
Oracle side in order to be able to test and maintain this code on
platforms we don't have access to. It's more work from both sides,
really, while so far we only had to update every now and then (btw, I'm
not afraid of the work, and I think OpenJDK would benefit from having
Cacio inside, but we all need to be aware it's not going to be trivial
effort).

> > Perhaps the peers should be more abstracted away, rather then
> > completely removed.
> 
> I don't think the idea is to remove the peers altogether.

I understood that they won't be accessible, which is the equivalent of
removing the peers from external code. My fear is that only internal
implementations will get to pass the platform checks, but I'm happy to
be proven wrong.

Of course, independent vendors can still adapt those things somehow, so
the scenario is less critical than it seems, but keeping things
compatible across JVM implementation just gets a little bit more
complicated now.

Cheers,
Mario