classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: java.io.File and its native methods


From: Archie Cobbs
Subject: Re: java.io.File and its native methods
Date: Sat, 24 Apr 2004 10:26:00 -0500 (CDT)

Etienne Gagnon wrote:
> > I'm not sure what the precise naming semantics are, maybe it would make 
> > sense to have interface that must be implemented by a VM into VM* 
> > classes, and classes that can be implemented natively in a different 
> > fashion in their own Platform* or Native* namespace. I'd prefer Native* 
> > since it 'sounds right' when the distinction is made about native methods.
> 
> Dalibor, you understood exactly what I meant: there is a difference between
> a native interface and a VM interface.  VM* classes should be reserved for
> such things that only a VM can implement (e.g. low-level primitive reflection
> functionality).
> 
> 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.

Hmm.. I agree that some native routines are more "VM oriented" (or
whatever) than others, but I don't quite see an obvious criterion
for distinguishing between the two. E.g., opening a file descriptor
is a thing that "only a VM can implement" is it not? Moreover, all
VM operations must be implemented via native methods, so at the
least there is a confusion in the naming of things.

Can you describe more explicitly how you would distinguish between
"VM interfaces" and "native interfaces" (and perhaps suggest better
names)?

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]