<AWT Dev> Caciocavallo (was Re: Removing all methods that use the AWT peer types in JDK 9)

[Mario Torre]

On Thu, 2015-02-19 at 17:30 +0100, Roman Kennke wrote:
> Am Dienstag, den 17.02.2015 um 13:55 -0800 schrieb Phil Race:
> > As I understand it, none of these can be exported from the java.desktop 
> > module.
> > Only standard Java SE APIs can be exported.
> > 
> > Which means that even if you made the core Cacio porting layer part of the
> > desktop module it would need to become part of the SE standard too.
> > Even if that were to happen,  all the ports you mention  that are not going
> > to be able to access those remaining internals you need such as 
> > SunGraphics2D
> > which are still private to the desktop module. Creating a multi-level SPI
> > that exposes as API all sorts of implementation code and concepts is
> > not a path we are likely to be resourced to help with.
> 
> Hmm. I am not totally familiar, but from what I heard at FOSDEM from
> Mark Reinhold, it is possible to export certain APIs *only to other
> known modules*. This is similar in concept to C++ friends, except it
> happens on a module basis instead of class basis. Which is fine. Could
> somebody from jigsaw please comment on this, confirm or deny if I'm
> wrong with my understanding?
> 
> So suppose we'd have a Cacio module that is part of OpenJDK (doesn't
> have to be part of any provided profile). Then the desktop module could
> export the required APIs to Cacio, without exporting it to anyone else.
> If I understand the modules stuff correctly.

This is what I understood too.

At that point, we can add another SPI as part of the Cacio module to
allow access to selected Sun*Graphics* etc.. things.

> If I'm wrong, I see no other way into the future for Cacio except
> building our own JDK. Which is not exactly an attractive option. Infact,
> it would basically kill it, I doubt our 'users' would be willing to go
> through the pain of building their own custom JDK, somehow magically
> link Cacio into the desktop module, and then that custom desktop module
> into their JDK.

I hope it doesn't come to that.

The main benefit of Cacio is the porting layer, but the real use case
has been over the years in testing. There's really lot of code around
that uses CacioTTA as a testing framework, this code will have to get
back at Fest or other tools now.

Cheers,
Mario