Re: PATCH for java.nio FileChannel and MappedByteBuffer

[Per Bothner <per at bothner dot com>]

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
> 100% independent.

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

> 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
> OS-specific files.

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" ...]
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/