Hi Casey, I just about exploded when I read the first part of your message ;-) But at the end of your message I discovered that we completely misunderstood each other and that we agree much more than we disagree.
With that in mind, here are my responses including to the parts that I initially found so inflammatory. (I know I'm an idiot for writing a response without having first read the entire message, but I can't help being passionate about this stuff.) Casey Marshall wrote: > OK. But I could argue back that VMs for whom native methods don't work > are broken as far a Java goes. True, but totally irrelevant. I said "native methods are very inconvenient for some VMs". IKVM supports native methods just fine, but that doesn't mean that they are a good idea. > I think you're saying that because platform details, like how files > and sockets work, are easier for you to implement "in the VM layer," > that they're necessarily VM-specific, and not platform-specific. > I couldn't disagree more with that. No, I'm saying that not all VMs are like the traditional C based VMs. BTW, this is not just IKVM, there are other Classpath VMs that also prefer to write their "native" code in Java. > There's also no rule saying that you have to use Classpath's > version of a class in your VM/system. That's true and sometimes I do decide to specialize a class (for example with the java.util.concurrent stuff) if the cost of using a VM interface is too high, but we all benefit if we share code. > > 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. > > Yeah, if I were writing a VM for Windows, I'd re-implement both. That has nothing to do with it. Just so you know, the *same* IKVM *binaries* run on Windows/Linux/MacOSX. The platform I code against is .NET/Mono, not the OS. That's also the reason why native code makes no sense for me. > If we keep the VM* interface thing, I think a better design is to stop > passing the core class to a static VM method, with the native state > inside the core class, and just make these VM classes > instance classes, with the native state associated with the instance. I thought that we already do that in most cases where it makes sense. > An example I'm thinking of is VMPlainSocketImpl. > PlainSocketImpl has an int field for the native file descriptor (and that > makes just plain no sense, either way), and passes itself to > VMPlainSocketImpl methods, which rips the descriptor integer out of that > instance. I think it's better to make VMPlainSocketImpl an instance class, > and keep the native state in that instance; in our default implementation, > this would be an integer file descriptor, and we'd have method pairs like so > in the VM class: I totally agree, but do you know why VMPlainSocketImpl is such a mess? Because it wasn't designed, someone just blindly applied the idea that native methods should be moved to the VM class. When VMPlainSocketImpl was introduced I should have stepped in and proposed something like what you just did, but I didn't because IKVM had already specialized the entire PlainSocketImpl class, so I was lazy and let it slide. > So the *interface* for the VM class is the public instance method, and > is the only one a VM writer needs to implement. Our default > implementation then just implements the function in the obvious, fast > way for POSIX. Maybe you can explain why passing an object to a static > method makes more sense than that (I can't see how; all it adds is a > litany of JNI calls to *every* method call). I think you *completely* misunderstood my position, as this is not at all what I was advocating. I completely agree with the VMPlainSocketImpl design you just proposed. Regards, Jeroen