This is the mail archive of the
mailing list for the Java project.
Re: PATCH for java.nio FileChannel and MappedByteBuffer
- From: Per Bothner <per at bothner dot com>
- To: gnustuff at thisiscool dot com
- Cc: java-patches at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Wed, 25 Feb 2004 23:22:30 -0800
- Subject: Re: PATCH for java.nio FileChannel and MappedByteBuffer
- References: <71211SSR3PNWRSQIYU8595KJZVJF.403d6fd5@p733>
Mohan Embar wrote:
First off, I've mentioned before that the symlink approach is the safest
way for me to guarantee that I can mess around with Win32 files and
not mess up the POSIX world. To use your patch as an example: yes,
you can argue that if _JV_WIN32_H is defined, then no amount of
messing up natFileChannelWin32.cc can adversely affect the compilation
of natFileChannelImpl.cc for the POSIX world, but when push comes
to shove, this is a harder sell than the guarantee that the two files are
If you break Posix after changing natFileChannelWin32.cc then
the bug is not in your change but in some other file: either the
configure script or whatever selects the correct .h file. Similarly,
if I make a change to gcc/config/i396/i386.h I know I might break
the CygWin port but I'm fairly confident I'm not go to affect PowerPC
- unless something I uncover some existing configure-related bug. That
is always possible, but unlikely.
For me, the crux of the matter is how different the OSes are. There is
variation among the POSIX targets, for example (HAVE_MMAP, HAVE_SYS_IOCTL_H,
HAVE_SYS_FILIO_H), but not enough to justify splitting this into separate
files. However, the Win32 and POSIX targets are different animals.
At one point in time. But is CygWin a Win32 or a Posix target? It's
obviously both. I can see a CygWin target using a mix of Posix or Win32
functions, depending on what functions are available in CygWin, what
has been implemented in libjava, performance, and application
integration. It's not a binary choice. Different releases of Windows
might support differnt subsets of Posix. I can imagine you'd might
want to use Gtk graphics on Win32.
Trying to divide the world into Posix vs Win32 is short-sighted and
taking your patch as an example, when I looked at natFileChannelImpl.cc,
the code for POSIX and Win32 was so different and there was so little shared
code, that I couldn't help wondering why this wasn't split up and put into the
I probably should create a separate natMappedByteBufferImpl.cc;
blame laziness for not having done so. But should I have moved
the code into separate natXxxPosix.cc and natXxxWin32.cc files?
There is something to be said for keeping the different
targets in a single file: Reasonable "dummy" implementations for
targets where we haven't implemented support. Though I haven't
made any attempt at an Ecos implementation, this way it is likely
that the library will compile and link on platforms where nobody
has implemented an implemented. Yes, I could create a
natMappedByteBufferEcos.cc, but what if we now add a forth "class"
of target, such as pre-OSX Mac? We'd need natMappedByteBufferOldMac.cc,
but it would be identical to natMappedByteBufferEcos.cc, which is silly.
But this is a different issue that using synlink or #include. The
latter allows us flexibility in terms of target-specific files,
or keeping it all in a single file, which is a separate style issue.
[This does seem to be turning into a "bikeshed discussion" ...]