David P. Grove wrote: > And if your VM is sufficiently weird enough (Jikes RVM with m-n > threading), then you might actually want to do something > different about files. We used to have our own version of > FileDescriptor and do non-blocking I/O with hooks back into our > threading layer instead of using the default classpath > implementation.
OVM does a similar "weird" thing. We have to redirect every "native" method to some library-glue that knows how to handle it correctly. Some simple things like getting a file length or checking existence of a file may be redirected back to an actual native method, but all actual I/O goes into the VM before emerging as some kind of native interaction. I'm quite happy with VMxxx for these classes - and much prefer this to PlatformXXX (because our VMxxx classes are NOT platform specific), and NativeXXX is incorrect because it is not native for us. The fact that all JNI-supporting VMs may be able to share the same native code doesn't mean that the choice of being native in the first place in not VM-specific. Making a method native is a choice - and that choice is up to the VM. Let the VMxxx methods have a default native implementation, but lets keeps those native declarations in the VMxxx file. If every "native" method were actually defined in a VMxxx class we wouldn't need our initial redirection of native methods to the library-glue code, we would just write the right code in VMxxx. David Holmes _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
