Re: java.io.File and its native methods

[Mark Wielaard]

Hi Etienne,

On Sat, 2004-04-24 at 08:54, Michael Koch wrote:
> Am Freitag, 23. April 2004 23:28 schrieb Etienne Gagnon:
> > This makes no sense whatsoever.  File is NOT VM-specific in any way.
> >
> > VM*.java should be reserved for the VM interface only.
> 
> The idea is to get native methods out of normal classes to make it 
> possible for some JVMs to use GNU classpath at all. This is the VM 
> interface in my opinion because some VMs dont wanna use our native 
> methods at all and currently they have to replace java.io.File. That 
> would be really bad and they have to take a look at each change in 
> java.io.File on each new release.

I agree in general with Michael. Although I have not yet taken a close
look at the patch he suggests (sorry). Could you be more specific about
why you say that it makes no sense whatsoever? If you are talking about
naming then I agree that VMFile might not be the most appropriate, but
we haven't come up with something better. Anthony Green once suggested
PlatformFile(Descriptor), maybe that describes better what/why we want
the split here.

The reason GNU Classpath has different layers and interfaces is so we
can more easily switch underlying implementations, see how/where the
platform dependent parts are and give people the opportunity to create
different platform specific things or optimizations.

I know that you (or pure JNI based implementations) and gcj (or pure CNI
based implementations) don't really care about this. "native is native."
But that is not really true (even between native JNI and native CNI
there are different trade offs when or how many "native" methods to
create for what). When someone wants to do most things in (pure or
extended) java or say Oberon then marking all core methods native
doesn't really help. And it prevents people from choosing a different
optimization strategy from the core implementation. I agree that if this
becomes a maintenance nightmare we might want to reconsider. But in
general it just looks like good common sense engineering describing
implementation dependent or optimization points.

I have tried to describe some of the different GNU Classpath layers in a
short workshop that we did last year at Linux Kongress.
"Hacking on the VM Interface"
http://klomp.org/mark/classpath/slides/gnu_classpath_workshop.html

It would be a good idea to have more of this explicit in the VM
Integration Guide. (doc/integration.texi is unfortunately hopelessly
out of date.)

Cheers,

Mark

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