Merge CacioWeb

[Roman Kennke]

Hi all,

Thanks Mario for bringing this up.

First of all let me explain what is Cacio and why we think it's useful.
In essence, it is an (somewhat) abstract implementation of AWT peers. It
implements all the AWT widgets by using Swing for painting and
event/logic processing. This reduces the burden of porting/implementing
the Java graphics stack enourmously. Currently, when one wants to port
the Java graphics stack, the AWT peers need to be implemented as well,
for compatibility. This is a huge effort, and considered rather
pointless by many, because AWT is not that widely used anyway. It is
particularily difficult on platforms that don't have any native widgets
(most embedded platforms). Using Cacio, this effort is reduced to
implementing a Java2D backend and some basic windowing functionality. It
even provides a windowing implementation in Java for platforms that
don't even support windows (e.g. framebuffers).


> On the other end, it could make more sense to include Cacio in the
> build process of the main JDK, especially since the only usable peer
> (and the only being actively developed) is currently the HTML5 one,
> and by integrating this in the JDK forest as well, my hope is to
> enable builds to pass (or be tested against) the TCK.

Well... I would like to point out that we do have implementations for
X11 (rather pointless to merge as the JDK has its own more complete X11
backend), SDL and DirectFB, which are not complete or very useful
currently, but we plan to finish both of them to state where they are
usable. We also have a somewhat special backend which renders
exclusively into a BufferedImage and can only process events generated
by Robot, which is particularily useful for unit testing GUI
applications without messing around with the user's desktop or without
requiring graphics on a continuous integration server (extremely useful
if you're into this GUI testing thingy).

To me, a very important aspect (as you pointed out) is to get access to
the TCK to actually verify that Cacio -based backends are compatible AWT
implementations. For this reason I guess we should also do a JDK7 based
version, as there's no TCK for Java8 yet AFAIK.

One more thing: Caciocavallo already *is* a project :-) I guess there's
not much to propose here. We even do have our own JDK7-based forest,
which is hopelessly outdated by now. So I guess the question is whether
we can:

1. Get a JDK8-based forest next to our JDK7-based one, which we would
bring up to date. We would integrate the Cacio code into those forests,
based on suggestions and discussions that we hopefully get.
1a. Try to get access to the TCK for the JDK7 forest.
2. Once those are working well, if there is interest, merge those
forests back into mainline JDK.

What do you think?

Regards, Roman

> I also hope that by having the code directly integrated in the JDK we will be able to reach more testers and fix more issues, since now Cacio is used in very specific environments only.
> 
> In addition to that, in order to support the web peer, we are implementing a number of features that will surely be beneficial for the Java ecosystem, like client filesystem support over the HTML5.
> 
> I believe that those additions could be very useful, and we call this project internally as WebJDK (spoiler: we will unveil something at FOSDEM if you would like to attend and are interested).
> 
> I know that based on the new rules I will have to formally propose a project, but before doing this I want to see if a formal WebJDK would be something interesting for the community and not only for us, and if Cacio would be likely to be integrated in the JDK, or if you prefer the current situation where it's a separate library.
> 
> If accepted, the WebJDK will include a custom JDK8 forest (or perhaps just the patches since are easier to manage) with all the code needed to enable web support (filesystem, deployment code, etc...), plus Cacio and the HTML5 peer code.
> 
> We will develop this in the JDK8 timeframe and hopefully merge everything that makes sense in the "real" JDK9 forest.
> 
> Any ideas, suggestions, criticism?
> 
> Thanks,
> Mario
> ---
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> 
> http://www.ladybug-studio.com
> 
> IcedRobot: www.icedrobot.org
> Proud GNU Classpath developer: http://www.classpath.org/
> Read About us at: http://planet.classpath.org
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
> 
> Please, support open standards:
> http://endsoftpatents.org/
> 
> 
> 
>