Re: VMFile confusion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 24 April 2004 22:12, Archie Cobbs wrote: So applying this logic, there should be no VMFile class because the native methods of File.java are all implementable in a normal Classpath-supplied shared library and are not VM-specific. Just curious; is there any platform dependent naming scheme? The simples example being that these files will have to be re-implemented under Windows if someone wants to port classpath? - -- Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAi3+YCojCW6H2z/QRApT0AJwM95y4sG6CFkL8CiR5vxJzzlAANQCgyGGw DQ5pDhYuIsxuI+lziTkLV4o= =TFuv -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMFile confusion
Am Sonntag, 25. April 2004 11:06 schrieb Thomas Zander: On Saturday 24 April 2004 22:12, Archie Cobbs wrote: So applying this logic, there should be no VMFile class because the native methods of File.java are all implementable in a normal Classpath-supplied shared library and are not VM-specific. Just curious; is there any platform dependent naming scheme? The simples example being that these files will have to be re-implemented under Windows if someone wants to port classpath? The idea is to only use different native code choosed at configure time, so no change in java code is needed. libgcj does this successfully since a long time. Michael ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMFile confusion
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. This got out of sync with classpath at some point and we don't use it currently, but something like it will come back eventually. On VMFoo vs. NativeFoo vs. PlatformFoo, I really don't care. I only observe that one person's VMFoo is another person's native/platfrom so perhaps it makes sense to just pick one name (VM) and leave it. I suspect you are unlikely to be able to nicely divide the classes along these lines so why waste any intellectual effort (and silly flame wars) arguing about whether something is a VMFoo vs a NativeFoo. --dave___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMFile confusion
Am Sonntag, 25. April 2004 13:40 schrieb David P Grove: 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. This got out of sync with classpath at some point and we don't use it currently, but something like it will come back eventually. On VMFoo vs. NativeFoo vs. PlatformFoo, I really don't care. I only observe that one person's VMFoo is another person's native/platfrom so perhaps it makes sense to just pick one name (VM) and leave it. I suspect you are unlikely to be able to nicely divide the classes along these lines so why waste any intellectual effort (and silly flame wars) arguing about whether something is a VMFoo vs a NativeFoo. That's the best mail I read about this so far. Thx. Michael ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMFile confusion
David P Grove wrote: On VMFoo vs. NativeFoo vs. PlatformFoo, I really don't care. I only observe that one person's VMFoo is another person's native/platfrom so perhaps it makes sense to just pick one name (VM) and leave it. I suspect you are unlikely to be able to nicely divide the classes along these lines so why waste any intellectual effort (and silly flame wars) arguing about whether something is a VMFoo vs a NativeFoo. This was exactly my thinking originally, and why I was inquring to Etienne about what he really meant, i.e., what is his dividing function, because to me there really is no such thing. However, after thinking about it I realized that he is right in a way. While in the grand scheme of things there I agree is no one true clear division between VM methods and native methods, in practice, by virtue of its implementation, Classpath has implicitly defined just such a dividing line. I.e., if Classpath supplies a native implementation of a method, then it's a native method.. if not, then its a VM method... at least within the context of Classpath itself. So if we belive Classpath being self-consistent is a good goal, then it does make some amount of sense that the naming scheme would be consistent with the VM/native split that it implicitly defines. NOW having said all this I should also say that it doesn't really matter to me either :-) I'm more curious in the underlying issues that motivate the discussion because they help me understand subtleties of VM design. E.g., Classpath has implicitly defined this line.. is that the best line? What line would you draw if you were starting over? (rhetorical questions, please don't answer on the list :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: VMFile confusion
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
