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

[Roman Kennke]

Hi Phil,

> >> 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,
> > So, in order to make Cacio stuff work with JDK 9, it needs to be part of the desktop module, in other words, OpenJDK code base. Sounds like it's time for a Cacio JEP :-)
> >
> 
> Not necessarily.  I imagine this would be a port of the desktop module 
> (to create
> your JDK) and ports don't have to be in the core openjdk code base and 
> indeed
> the bar for that is understandably high.

Not sure I understand what you mean. If you mean to effectively fork the
whole desktop module, I don't see that working well. Maybe it helps the
discussion if I outline what Cacio actually is and does. Compared to the
whole desktop module, Cacio is a super-tiny piece of software that's
comprised of:

- A porting layer for AWT widgets. This implements the peer interfaces,
and uses Swing to provide AWT widgets. Very useful on platforms that
don't provide any native widgets, or if you're simply too lazy and don't
care about AWT ;-)
- A windowing layer that basically provides heavyweight windowing all in
Java. This implements some interfaces of the above AWT porting layer,
and can provide HW windowing, for example, on systems that only have a
sort of graphics/framebuffer, but no native windowing.

The above are only support layers and don't do much themselves. We also
have a number of actual ports that use the above 'core' Cacio stuff,
plus tons of stuff from the desktop module (namely, SunGraphics2D,
SurfaceData, fonts, etc):
- An SDL port
- A DirectFB port
- An implementation that only renders into BufferedImages and uses Robot
to simulate events. This is extremely useful, and infact used by
customers for GUI testing.
- An implementation that renders into an HTML5 canvas using a
webbrowser. I.e. Swing application runs on a server, client accesses it
through a browser. Browser renders graphics using JavaScript/HTML5 and
sends back events to the server. We call this CacioWeb ;-)

I am not sure what would be the best way to move into JDK9/module land.
Forking the whole desktop module or OpenJDK for that matter doesn't
sound attractive to us. We'd much more prefer if Cacio could somehow be
included become part of OpenJDK. Maybe as a separate module (or number
of modules? One per actual port, plus the core?) The way it's done now,
it doesn't affect any of the existing code (except for the outstanding
x11fontmanager patch..). Before modules, what you need to do is simply
put the cacio JARs into the classpath, and pass some properties to load
a different toolkit and graphicsenv, and that's all. It required us to
keep track of changes to internal peer APIs, but that was only a minor
pain so far. However, if modules prevent us access to internal APIs like
SunGraphics2D and SurfaceData, or even the peer interfaces, this is
going to be a problem.

Would the be any interest in supporting a Cacio JEP? I believe it would
be a useful addition to OpenJDK. It would help tremendously to bring
AWT/desktop support to platforms that otherwise don't have any native
widgets or windowing, e.g. most embedded platforms. Infact, the MacOSX
AWT stuff looks in some places very similar to Cacio. ;-)

What do you think?

Best regards,
Roman