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

Reply via email to