Re: java.io.File and its native methods

[Mark Wielaard]

Hi,

On Sat, 2004-04-24 at 14:41, Etienne Gagnon wrote:
> To classpath maintainers: If you want to separate all native calls to Native*
> classes, I don't care, but please do not mix the VM* interface and the
> Native* interface.  They are semantically quite different things.  I am 
> suprized
> that this is not plain obvious to some of you.

As others have explained it is not so clear cut as you make it out. For
example some of our reference JNI methods expect that the VM JNI
interface allows that final fields can be set or whether a class has a
static class initializer. Something that is not specified by the JNI
spec. For other things we do provide reference implementations that are
helpful for runtimes but that are clearly not as efficient as when a VM
does it more directly. The VM* classes indicate that there is something
the runtime hacker might want to take a look at to make sure the
implementation is optimal/useful for their platform.

In the future it would help if you take a less aggressive tone when you
comment on someones patch. Starting your review with "This makes no
sense whatsoever" and then not giving any suggestion what you would like
to see changed or how isn't helpful. You could just have said "I suggest
we call this new class PlatformFile.java instead of VMFile.java because
...". Then nobody has to guess why you have an issue with a certain
patch.

I don't really mind if you want to submit a patch to rename those VM*
classes to Platform* classes when there is at least a reasonable default
reference implementation for all methods in either java or JNI/C/Posix.
Please do. It would certainly clean things up if done consistently
throughout the whole code base. But if nobody wants to do that then I
think having them all called VM* is better then some being called
Platform*, some Native* and some VM*.

Thanks,

Mark

signature.asc
Description: This is a digitally signed message part