Native libs & AWT (Was: Re: Further cleanups (Was: Re: [kaffe] dealing with gjdoc))
Andrew John Hughes
gnu_andrew at member.fsf.org
Thu Jan 17 06:50:06 PST 2008
On 17/01/2008, Dalibor Topic <dalibor.topic at googlemail.com> wrote:
> Andrew John Hughes schrieb:
> >> I take it the Qt peers mentioned are ones that ship with Kaffe as
> >> opposed to the Classpath ones (which are also dormant)? If there's
> >> anything worth salvaging, it might be best to throw it over the wall
> >> to Classpath.
> Yes, they are. I think the interesting part is that they also worked
> with Qtopia, but I believe
> there are patches in the Classpath bug tracker for the ones in Classpath
> to make them build
> with Qtopia, too.
Yeah, we really need to get on top of our bugs and mislaid patches... :(
> Concentrating on one Qt peer implementation, provided someone cares
> about maintaining them,
> is better then having two different efforts, and GNU Classpath's
> AWT/Swing is a lot better than
> what old Kaffe AWT has to offer.
Yeah, I was thinking more if there was any code worth porting to the
GNU Classpath peer framework.
> >> * GNU MP big math
> >> I'd like to remove the feature and let GNU Classpath handle it for the
> >> next release.
> >> There is a patch from Raif for GNU Classpath that proposes an
> >> implementation of that feature for GNU Classpath, it would need someone to move it to the point
> >> where it could be merged into Classpath proper. The PR is Classpath/28664 in Classpath's
> >> bug tracker.
> >> The feature belongs into a class library, rather than a VM, in my opinion.
> > The bug seems to have been inactive for the best part of a year and a
> > half. Where's the patch you mention? Has it been applied to
> > Classpath? It's not attached to the bug tracker or mentioned there.
> It hasn't been applied yet. It's waiting for someone to review it. See
> for the last version.
I'll try and take a look. From that mail, it seems it will at least
need moving to a VM interface.
> > With both zip and GNU MP support, there's a question of whether a
> > native or Java-based implementation is better. Classpath currently
> > has Java-based implementations of both, which is an advantage for
> > Java-based VMs over OpenJDK, etc. but a performance issue for other
> > VMs such as Kaffe.
> Depends on the situation. For example, using Classpath's pure java zip
> on x86, with jit3, is about
> as fast as using the zlib zip for me. I think choice is interesting for
> the situations where people deploy
> the free VMs on platforms with limited resources, but from a project
> management perspective, the
> less class library code is in a VM project, the better. ;)
> > Maybe we need to provide alternatives perhaps via
> > a property that can be set by the VM? (Doing it at configure time
> > would make things tricky as the user or distro then has to choose, and
> > the VM would have to determine how Classpath was built, etc.)
> I don't think so. In general, doing that dynamically makes it all very
> complicated, and provides no
> benefit for the situations where you want to use the alternative
> implementation, as you'd want to
> configure out the features you don't use on limited devices anyway.
> Let the distro / deployer make their choices, they should know what they
> are doing best. They
> can always simply build a couple of different Classpath configurations
> to play with, and build a
> VM against each, if they want to test configurations out.
Yeah, you're probably right :)
In the case of GMP, it should probably be the default once more
throughly tested as I'm guessing there are quite a few holes in our
> dalibor topic
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
More information about the kaffe