Casey Marshall wrote: > Tom Tromey wrote: > > It seems to me that this is an area we haven't handled very > well: this > > isn't really a "VM" thing per se -- the code could very well be > > written in pure java -- but rather a platform thing. > > > > I agree that adding special cases in File just makes the code uglier > > and uglier. But, we could delegate to a pure java "platform" class, > > with instances for "posixy", Windows, Windows CE, etc, and share the > > code across all VMs. > > > > We do something vaguely similar to this in libgcj (though in the > > specific case of File we put the platform stuff in native code). > > > > FWIW I agree. Some of us were chatting about this on IRC, and not only > are these "VM" interfaces more often than not platform interfaces (or > with some things, all they rely on is JNI and standard C), but they do > lead to performance hits (witness our direct ByteBuffer). > > I think putting some design thought into this is a good idea, because > right now I don't think we have any clear idea about what the scope or > purpose of VM/platform interfaces are. Right now, it looks like it's > just an ad-hoc catch-all for anything that can't be done in > pure Java -- you slap a VM class on it, and hack up the core class.
I disagree. In most cases the VM decides what platforms to support and how to do this, so it does make some sense to move this stuff into the VM interface. This combined with the fact that native methods are very inconvenient for some VMs (like IKVM), we decided to add this extra indirection layer where the VM can decide to do things differently. I realise that for gcj people it may look like there is a significant difference between (e.g.) VMFile and VMThread, but other VMs replace both these classes. BTW, if there are specific cases (like ByteBuffer you mention), I'm more than willing to discuss alternatives to find a better alternative to suites everyone. I think that in many cases the VM interface design suffers from the fact that not enough VM implementers participate in the design. Regards, Jeroen
