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

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