21 May 2004
GTK+ AWT peers now on Kaffe
Thanks to the hard work of saugart and jserv (and of course the GNU gcj hackers who worked so hard on the actual AWT peers) Kaffe can now also use the GNU Classpath GTK+ AWT peer implementation (see the announcement, including sweet screenshots).
This is really nice since it brings GNU Classpath and Kaffe OpenVM closer together. And as always when a new set of people start using a piece of free code in new and unexpected ways we found (and fixed!) some bugs (just minutes after the integration). This will really be a boost for the project because it exposes much more people and programs to the code. And it will be the start of the Free Swing integration into Kaffe.
Hacking on KDE with gcj for fun
Helped Boudewijn Rempt recently with getting kde/qtjava working with GNU gcj. It was really fun. And all it took was about three minutes. One to get us a traditional byte code interpreted version with gij. One to get us a complete monolitic native program. And finally another one to split it up in a reusable native shared library ready for linking with other programs. He made a little Creating `native’ Qt applications with Java tutorial out of it. What was really nice was that his SUSE 9.1 box came with everything ready to hack in standard packages. Richard Dale made some additional observations which are also nice to read.
The only thing I need to clarify is this comment that Boudewijn made: “Mark Wielaard tells me that for every JNI call, gij is called to generate some bytecode, which is then executed. Things could be faster, he tells me.” Which is not correct. JNI is not as fast as CNI, which we prefer to use with gcj specific code, but it is fast enough for this use. It doesn’t need to generate extra byte code that needs to be interpreted. What I had wanted to say was that the KDE java bindings use a lot of java.lang.reflect.Proxys. These are currently implemented by creating on the fly byte code that then needs to go through the byte code interpreter. The framework for replacing this with direct native code is there, we just need an interested hacker to write it and wire it up to the rest of the gcj runtime. It is a nice little challenge for someone that want to dive into the gcj runtime.