classpath
[Top][All Lists]
Advanced

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

Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl


From: C. Brian Jones
Subject: Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
Date: Tue, 11 May 2004 23:39:46 -0400

On Tue, 2004-05-11 at 20:41, Per Bothner wrote:
> Steven Augart wrote:
> 
> > Michael Koch wrote:
> 
> >> What if someone wants to port GNU classpath to an Operating System 
> >> with totally different semantics like Windows ?
> > 
> > If someone does that kind of port, he'll have more problems than just
> > than the size of a file descriptor.
> 
> I think Michael was being ironic.  I haven't checked the current
> Classpath, libcj (which shares most of its code with Classpath)
> certainly supports Windows.
> 
> I think the cleanest solution is to allows FileChannelImpl to be
> subclassed, or to uses different classes that implement FileChannel.
> But the current code works fine for now.
> 
> For JNI performance I don't see any reason not to not to have the
> Java code pass the "native" fd field to the native method - just
> realize that if/when Classpath gets ported to a system that
> uses 64 pointers we may have to redo things.  One solution
> may be to use the Posix API.
> 
> The Posix IO functions (open/read/write etc) are available on
> Windows.  I don't know why they're not used - performance?

I don't really know, Orp developers used the Posix stuff in Windows for
implementing Classpath's JNI methods some time back.  Then some folks in
GCJ land decided they'd be better off using the native Windows API.  The
changes are pretty small to use Windows Posix API vs what we do today. 
Is the current JNI code compatible with a 64 bit system?  Can you open a
file larger than 4G or whatever it is and use the whole thing?

Brian

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


reply via email to

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