This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: FYI: Patch: java nio file locking
- From: Michael Koch <konqueror at gmx dot de>
- To: Per Bothner <per at bothner dot com>
- Cc: Michael Koch <konqueror at gmx dot de>, java-patches at gcc dot gnu dot org
- Date: Fri, 23 Jan 2004 22:31:51 +0100
- Subject: Re: FYI: Patch: java nio file locking
- References: <200401231542.26164.konqueror@gmx.de> <4011697A.9080800@bothner.com>
On Fri, Jan 23, 2004 at 10:35:38AM -0800, Per Bothner wrote:
> Michael Koch wrote:
>
> >I commited the attached patch to add java NIO file locking to trunk.
>
> This is conflicting (and breaks) work I'm doing. I'll fix it, but
> it would be helpful to know if you'll be going more work in this
> area - and it may be helpful for you to know what I'm doing.
>
> (1) My main goal (i.e. what I'll be getting paid for) is to
> implement memory mapping, at least read mapping.
Cool.
> (2) As part of that I'm trying to better integrate java.io and
> java.nio. Specifically, I'm merging java.no.channels.FileChannelImpl
> into java.io.FileDescriptor, and totally removing FileChannelImpl.
> That seems a simpler and more efficient architecture. We might
> consider moving things in the opposite direction: merge FileDescriptor
> into FileChannelImpl and get rid of java.io.FileDescriptor, though
> that's a slightly bigger change. If so, I'd like to use a single
> natFileChannelImpl.cc file with conditional compilation, rather than
> 3 files like we do for natFileDescriptorXXX.cc.
I wonder how do you wanna implement anything file channel related when
you remove FileChannelImpl. Note that FileChannel is abstract but some
methods in NIO return a FileChannel object.
I would prefer a single natFileChannelImpl.cc too but the windows people
namely Mohan Embar requested the split.
Michael