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.
I agree in general with Michael. Although I have not yet taken a close look at the patch he suggests (sorry). Could you be more specific about why you say that it makes no sense whatsoever? If you are talking about naming then I agree that VMFile might not be the most appropriate, but we haven't come up with something better. Anthony Green once suggested PlatformFile(Descriptor), maybe that describes better what/why we want the split here. 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. I know that you (or pure JNI based implementations) and gcj (or pure CNI based implementations) don't really care about this. "native is native." But that is not really true (even between native JNI and native CNI there are different trade offs when or how many "native" methods to create for what). When someone wants to do most things in (pure or extended) java or say Oberon then marking all core methods native doesn't really help. And it prevents people from choosing a different optimization strategy from the core implementation. I agree that if this becomes a maintenance nightmare we might want to reconsider. But in general it just looks like good common sense engineering describing implementation dependent or optimization points. I have tried to describe some of the different GNU Classpath layers in a short workshop that we did last year at Linux Kongress. "Hacking on the VM Interface" http://klomp.org/mark/classpath/slides/gnu_classpath_workshop.html It would be a good idea to have more of this explicit in the VM Integration Guide. (doc/integration.texi is unfortunately hopelessly out of date.) Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
