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.
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.
* 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
http://article.gmane.org/gmane.comp.java.classpath.patches/11222/match=classpath+gnu+mp+28664
for the last version.
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.
cheers,
dalibor topic
_______________________________________________
kaffe mailing list
[email protected]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
