Hello all, I would like to ask a question about the future directions for Caciocavallo, and CacioWeb.
As you may already know, Cacio is a project we started for the OpenJDK Innovators Challenge and was aimed at refactoring the graphics code in OpenJDK to allow custom peers (and hence easy the portability of the platform to new systems). It evolved from the set of patches necessary to allow plugging of a custom backend, to a full abstract implementation of the AWT peer code and has been quite successfully used in commercial environments for quite a lot of time, and it is now in maintenance mode since at least a couple of years, apart from some small patches and fixes that land from time to time. I think that the level of activity justifies to start thinking about the future and the final merge of the project on the JDK repositories (I think JDK8/JDK9 timeframe would be the goal). As I introduced, Cacio started as a series of JDK6 patches to enable custom graphics backends (and required a custom build of the JDK at the time), but those patches were all formally included in the JDK7, so today is already possible to use a Cacio based peer on JDK7 onward by just adding the shared Caciocavallo and peer code jar file without any extra patch or custom build. This makes a lot of sense, since Cacio is formally separated by the JDK, but at the same time puts some efforts on our side, since we need to maintain different versions of the project for each JDK release (major release). We decided to address this issue by only following the latest development version, while we tag a release where backward compatibility is known to break, and this approach seems to work quite well. 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. 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/
