This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH for java.nio FileChannel and MappedByteBuffer

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 can adversely affect the compilation
of 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 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,
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; blame laziness for not having done so. But should I have moved the code into separate and 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, but what if we now add a forth "class" of target, such as pre-OSX Mac? We'd need, but it would be identical to, 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]