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
_______________________________________________
kaffe mailing list
[email protected]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
