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

[Dalibor Topic]

Dalibor Topic wrote:
> I'll look into removing unnecessary function and header tests from 
> configure next, 

Done.

* Native libs

> and then look into rewriting the remaining KNI code to
> use JNI, so that we can remove kaffeh, and just use javah from GNU 
> Classpath instead.
The strategy that I'd like to pursue here is to try to take as much code 
as possible from Cacao,
(or OpenJDK, where possible) and to replace our implementations with it, 
as they use JNI
already. Cacao's current mercurial repository has a mostly complete 
implementation of
sun.misc.Unsafe, for example, that we need to make the 
java.util.concurrent package work
properly on Kaffe.

* old kaffe AWT

I'm currently cleaning up the old kaffe AWT to make it build again. I'll 
remove the classes
copied over from GNU Classpath as far as possible, but I won't put work 
into making the
Xlib peers actually work.

Is someone interested in maintaining the old kaffe AWT code for 1.1.9? 
I'm sure the X peers
are broken currently from looking at the compiler warnings, the qt peers 
probably don't
build any more with Qt /  Qtopia releases, etc.

If no one steps forward to maintain them in the four weeks, I'd like to 
mothball them. If we
can't support class library features, there is no point in shipping them 
as part of the release,
in particular since class library features as such are better suited for 
GNU Classpath.

* 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.

* zlib zip

It breaks static VM builds atm, so I'll turn it off for the default 
build. I don't want to
remove it, since otherwise life would be very ugly on platforms with 
just the interpreter
engine.

But I'd like to try to rip it out and replace it with the implementation 
from
OpenJDK, which also uses zlib internally. Chances are the Classpath/OpenJDK
hybrid class library BrandWeg, announced by Andrew Hughes, will 
eventually use
OpenJDK's zip implementation, then we'll be able to rip the code out 
completely.

cheers,
dalibor topic