On Thu, 31 Oct 2002, Andy Walter wrote: > Hi, > > On Thursday 31 October 2002 12:15, Mark Wielaard wrote: > > Has someone actually tried Rudolph with GNU Classpath? > > Yes, it is running quite well here. But we replaced many native methods (all > but 5) by Java code. Since Rudolph uses a proprietary interface, this > replacement might be interesting for classpath. On the downside, our > implementation diverged from Rudolph.
To clarify what happened here: a little before Wonka (and Rudolph) went open source, we did a deal with Aicas that they could take the Rudolph code and adapt it for their VM, provided that they gave us back their modified version (using JNI rather than our proprietary interface or theirs). Aicas kept their side of the bargain, but we never found time to integrate their changes into our source tree (which of course had moved on since the snapshot we gave them). So Aicas are in possession of an Authorised Fork. ;> > > Also take into account that Wonka contains only the java.awt, > > java.awt.event and java.awt.image packages. We have that and > > java.awt.color, java.awt.datatransfer, java.awt.dnd, java.awt.dnd.peer, > > java.awt.font, java.awt.geom, java.awt.im, java.awt.im.spi, > > java.awt.image.renderable, java.awt.peer and java.awt.print. The > > important advantage that Rudolph has is of course that the code that > > they have actually works! > > Not only that but it also doesn't depend on GTK. I think it would be great to > separate the top level graphics stuff from the low level peer classes by a > common, well-defined interface. That way had three sets of peer classes > (GTK-based, acunia framebuffer, jni framebuffer), but only one common set of > top level classes, which are probably much more (I have to admit that > personally, I don't have to do much with graphics). > > I expect that the sooner we agree on such a common layer, the fewer redundant > work there is on the top level. A while back we started to convert all Rudolph classes to use peers, with Rudolph's framebuffer/XImage peers as the default (and currently only) implementation. A few classes (e.g. java.awt.Font) are still in the old "monolithic" form, until someone feels brave enough to make the split. SImilarly we intend to replace the current proprietary interface with JNI at some not-too-distant future time. One of the motivations for doing so is that it would then be possible to use other sets of peers (e.g those of the Classpath AWT) with Rudolph. > > And please make sure that all arrangements between Acunia and the FSF > > are made clear and public. The last deal that was done with respect to > > the AWT code (with Transvirtual) was never communicated clearly and that > > produced some tensions. (I am perfectly happy to let RMS try to get a > > deal that is in the best interest of all free software users as long as > > it is clear in the end what has been decided.) > > RMS for sure is the right person to do this. I had expected all agreements of > the FSF to be made public and am surprised to read this wasn't the case with > Transvirtual. Amen. There has been some off-list discussion of this, but I would expect any deal that is done to be done openly. -- Chris Gray VM Architect, ACUNIA _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
