|
From: | Dalibor Topic |
Subject: | Re: java.io.File and its native methods |
Date: | Sat, 24 Apr 2004 13:53:19 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 |
Hi Mark, hallo Michael, salut Etienne, Mark Wielaard wrote:
Hi Etienne, On Sat, 2004-04-24 at 08:54, Michael Koch wrote:Am Freitag, 23. April 2004 23:28 schrieb Etienne Gagnon:This makes no sense whatsoever. File is NOT VM-specific in any way. VM*.java should be reserved for the VM interface only.The idea is to get native methods out of normal classes to make it possible for some JVMs to use GNU classpath at all. This is the VM interface in my opinion because some VMs dont wanna use our native methods at all and currently they have to replace java.io.File. That would be really bad and they have to take a look at each change in java.io.File on each new release.
s/possible/easier :)If one is not using Classpath's native libs, then merging code back and forth is rather painful at times. Encapsulating the native layer in its own namespace is helpful in that respect at least, so I'm supportive of the idea. It also allows me to encapsulate Classpath-specific library names like "javanio" in their own class easily, so that I don't get pseudo-diffs because our native libraries names' differ from Classpath's.
I'm not sure what the precise naming semantics are, maybe it would make sense to have interface that must be implemented by a VM into VM* classes, and classes that can be implemented natively in a different fashion in their own Platform* or Native* namespace. I'd prefer Native* since it 'sounds right' when the distinction is made about native methods.
The reason GNU Classpath has different layers and interfaces is so we can more easily switch underlying implementations, see how/where the platform dependent parts are and give people the opportunity to create different platform specific things or optimizations.
Yes, please! I'd like to have the same change for java.util.zip, for example, where some implementations use Classpath's pure java one, and others use zlib based ones. Ideally, it should be possible to ship both, and let the user/packager/deployer configure that at run-time/build-time. With Kaffe's primitive interpreter the pure java zip is no fun on slow platforms and lets class loading take awfully long:)
cheers, dalibor topic
[Prev in Thread] | Current Thread | [Next in Thread] |