Re: FYI: Patch: java nio file locking

[Per Bothner <per at bothner dot com>]

Mohan Embar wrote:

> I'd prefer split files for the same reason we decided to split the networking
> files.
>
> Initially, I was resistant to this idea:
>
> http://gcc.gnu.org/ml/java/2003-02/msg00168.html
>
> ...but this post convinced me otherwise:
>
> http://gcc.gnu.org/ml/java/2003-01/msg00093.html

This is not convincing to me.  Compare this alternative:

jint
java::io::FileDescriptor::read (void)
{
#ifdef POSIX
   ...
#elif WIN32
   ...
#else
  JVThrow(...);
#endif
}

The advantage of separate files is that the files are smaller, so there 
is less to scroll through and possibly scan through.  The disadvantages 
include:
* Extra configure/makefile magic.
* Tools (debuggers, indexers, IDEs) may get confused.
* Difficult to share code.  For example checking for index violations is 
likely to be system independent.
* This encourages extra private methods, to share code.
* Does not grow well to other OSes.  It assumes we only care about 2 (or 
3) OSes.  (Is somebody maintaining the Ecos code?)  What if someone 
wants to add support for (say) MacOS classic?  Some other embedded OS? 
They are unlikely to make a consistent set of new files, and I don't 
think we want them to.
* Incompatible with autoconf feature tests.

How about a compromise:
natFileChannelImpl.cc would contain:

#include <config.h>
... other shared includes ...
... other shared code ...
#ifdef POSIX
#include "natFileChannelImplPosix.cc"
#elif WIN32
#include "natFileChannelImplWin32.cc"
#elif ECOS
#include "natFileChannelImplEcos.cc"
#else
#error
#endif

This at least removes the confiuration/make magic, as well as
any potential problems with other tools.  It also allows a mix
of shared native methyods and non-shared methods.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/