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
