Re: Native libs & AWT (Was: Re: Further cleanups (Was: Re: dealing with gjdoc))

On 17/01/2008, Dalibor Topic <[email protected]> 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
> http://article.gmane.org/gmane.comp.java.classpath.patches/11222/match=classpath+gnu+mp+28664
> 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
implementation.

> cheers,
> dalibor topic
>

Cheers,
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net