Re: PATCH for java.nio FileChannel and MappedByteBuffer

[Mohan Embar <gnustuff at thisiscool dot com>]

Hi Per,

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

True, but I remember from the 3.3-days that towards the end of 3.3, I had
to forego making some Win32 networking-related bugfixes because everyone
was too afraid of the POSIX code breaking. As strange as it may seem with
people like us, sometimes the psychological aspect outweighs the theoretical
one.

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

Cygwin is a POSIX target. And I don't think we're dividing the world
into POSIX vs. Win32 - only where it make sense. There are plenty of native
files that are common to POSIX and Win32. IMO, any functions that Cygwin
needs should either go into Cygwin (backtrace() comes to mind) or else
in some sort of separate Cygwin-libjava helper library that autoconf can
feature-test.

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

At worst, I find files with #ifdefs like these both tedious and confusing.
I was tearing my hair out when I had to understand all of the #ifdef paths
in the networking code in order to figure out which I could rip out. At best,
they turn into simple shells around target-specfic includes, in which case
I have a hard time seeing the advantage of these over symlinks.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/