Hi,
Here is the work in progress for a new project I named apr-java.
It offers a 'thin' layer using JNI over APR library. The initial code that I wrote over a year now had two way api, but I've decided to leave only Java->APR.
I also have a working set of configure and make files for unixes, but since this is an overview of the technology, it's only a small subset of entire project, but you can get the picture :) .
It will support around 90% of APR API (without things like strings, etc. that are well done inside java itself).
The API itself on the Java side is done as close to the APR function call (apr_file_write -> File.write) with almost the same function parameters as well.
You can see that the wrapping code is very thin in most cases with only a couple of lines for each function, mostly caused by pointer issues.
I'm sending the gz file (tried zip but failed) so you can see what the general idea is. Of course the library can be extended with functions that APR doesn't offer (for now or never will). One of the things would be setting user and group for a process, sending data from parent to child process, etc.
The question is: Is it acceptable (think that previous discussions say it is) Where to put that in the cvs.
Comments?
Looks good.
It seems it still does a lot of String operations in native - unlike SWT for example, where it's almost always byte[]. Also the typical memcpy, etc should be included somewhere to allow data to move from/to the pool and java heap.
Why not checking it in j-t-c ?
Just to make sure - you expect it to also have non-apr native methods ?
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
