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

[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.

Putting Cacio in another module does not help that in anyway.
Different parts of the JDK are not allowed to reference internals of other
JDK modules. Or more generally modules  export specific packages
and everything else is inaccessible. We are having to make painful\
changes because of that.

The peers are a minor detail here. Even if they were not an issue all
the other visibility changes are all going to happen.

So the most plausible way forward that I can see is that you build a 
java.desktop module
that has your port in it.  This will get linked together with the rest 
of the JDK modules
when the developer uses jlink to build a custom JDK.

So I think you are going to need to talk to the people working on the 
module system.
None of this is something we are "changing" in the desktop area, its a 
direct consequence
of the JDK 9 module system which impacts JDK code a lot too and is under 
their control,
not ours.

-phil.

On 2/17/2015 1:22 PM, Roman Kennke wrote:
> 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
>