Re: java.io.File and its native methods

[Dalibor Topic]

Hi Mark, hallo Michael, salut Etienne,

Mark Wielaard wrote:
> 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.

s/possible/easier :)

If one is not using Classpath's native libs, then merging code back and 
forth is rather painful at times. Encapsulating the native layer in its 
own namespace is helpful in that respect at least, so I'm supportive of 
the idea. It also allows me to encapsulate Classpath-specific library 
names like "javanio" in their own class easily, so that I don't get 
pseudo-diffs because our native libraries names' differ from Classpath's.

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.

> 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.

Yes, please! I'd like to have the same change for java.util.zip, for 
example, where some implementations use Classpath's pure java one, and 
others use zlib based ones. Ideally, it should be possible to ship both, 
and let the user/packager/deployer configure that at 
run-time/build-time. With Kaffe's primitive interpreter the pure java 
zip is no fun on slow platforms and lets class loading take awfully long:)

cheers,
dalibor topic