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

[Roman Kennke]

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.

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.

Regards,
Roman


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