Brian Jones wrote:
Dalibor Topic wrote:
On Mon, 2006-01-30 at 12:20 -0500, Brian Jones wrote:
It would be nice, I believe, to re-use libraries that have handled
most of the "porting" and "wrapping" for you such as APR
(http://apr.apache.org/), or NPR
(http://www.mozilla.org/projects/nspr/) to platforms GNU Classpath
might care to support. You might also find glib useful,
http://developer.gnome.org/arch/gtk/glib.html.
I believe that's the reason why neither APR nor NSPR (nor other similar
projects) have seen wide spread acceptance, even though they have been
around for many years now: they don't really pay off enough for people
to rewrite their existing code bases to them.
Okay, but I brought it up since the work Guilhem Lavaux is doing sounds
an awful lot like a rewrite. Although technically I think you can just
run the macro processor by hand to get the current real source code for
say Linux and autoconfiscate it from there. Or you could go back a
couple of years and look in native/ for the original autoconf/posix
version of the libraries and move forward from there.
See also what the OpenBSD developers did as one of the first things,
once they 'forked' Apache web server 1.3.x after the Apache license
change: rip out APR and replace its use by plain old posix functions,
since those were more maintainable for them.
Yea, I think the point for me would be to keep Classpath's java hackers
out of the business of writing native code, and especially out of the
business of porting native code for such common idioms as generic file
operations, network operations, etc.
Hi Brian,
The code is not really a rewrite. Actually I am just moving out TARGET
layer and replacing it with native function call with an API not so
different than posix. My idea is that these function calls should be
purely POSIX (so that classpath's hackers does not have deal with
subtleties). Anyway, as I have already said it, seeing the amount of
code to do pure administrations in the JNI world, it is easier to read
autoconfiscated code which is completely outside the JNI code (again
look at javanet).
The advantage of this method is that some VMs may want to reroute these
syscalls and it is easy to do so using this semi-abstract interface
without rewriting anything.
Regards,
Guilhem.
