Hi Casey, On Thu, 2005-07-07 at 23:17 -0700, Casey Marshall wrote: > One feature this implementation requires, in order to function > properly, are file locks, which to my dismay are still not > implemented. On that point, I'd like to ask what the requirements on > JNI code are for Classpath, if any. I know there are at least two > "standard" APIs in Classpath for native functionality -- the > TARGET_NATIVE macro nonsense, and the VM* classes (I get the feeling > that the latter is preferred now). Should file locks (and, say, > memory-mapped files) use one of these? Or would it be acceptable to > simply write the JNI code directly, surrounded by appropriate #ifdef's?
The VM* classes and the TARGET_NATIVE macros are on two different "layers" of portability. The VM* classes make it possible to replace our java/POSIX/C/JNI default implementation from vm/reference with a version that uses CNI, C# or something completely different if the runtime writer wants that. The TARGET_NATIVE macros provide (an admittedly awkward) way to write "portable" C code. I think you should feel free to ignore them for new code since they make the code unreadable and debugging a nightmare. And they don't provide us any extra portability in practice since there is only one implementation. Please write clean (were possible autoconf-ed) GNU/Posix JNI C implementations for any VM* class in vm/reference. More "requirements" (goals) are here: http://www.gnu.org/software/classpath/docs/hacking.html#SEC10 Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches