Re: FYI: Patch: java nio file locking

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Mohan" == Mohan Embar <gnustuff@thisiscool.com> writes:

>> * Extra configure/makefile magic.

Mohan> - We already know how to do this and are doing this in many other
Mohan>   places in configure.in. It's pretty boilerplate now.

Yes, and we could wrap it in a macro if really necessary.

>> * Difficult to share code.  For example checking for index violations is 
>> likely to be system independent.
>> * This encourages extra private methods, to share code.

Mohan> This is the crux of the matter for me: if there is a lot of
Mohan> code sharing, I would me more open to this. But in the specific
Mohan> file you were looking at: natFileChannelImpl.cc, how much
Mohan> common code were you seeing?

We picked our current approach because sharing wasn't working very
well.  We ran into problems with it -- at least for networking,
Windows and Unix were too different (while being superficially
similar) to make it work.  Also it is fragile in that it is hard to be
certain whether a given change is safe.  With the current approach we
can make (e.g.) POSIX-specific bug fixes without affecting the Windows
port, and for API changes we can get a Windows maintainer to write the
new code.

I agree it might be useful to share certain bits of code.  We can
write utility functions for this.  For some things, like index
checking or character set conversion, it would benefit other parts of
the native code, not just the platform-dependent code, to do this.
(Cue Mohan to note the discussions about utf-8 conversion classes... :-)

>> * Incompatible with autoconf feature tests.

Mohan> Can you elaborate on this more?

The autoconf philosophy is that one should test features and not
platforms.  There's a lot of evidence showing that this is the
superior approach in most situations -- e.g., a history of programs
porting to a new platform with little (or zero) work.

However, this approach does have limitations.  The overall approach
we've adopted is to have OS "flavors" which are basically families of
operating systems.  Within a given flavor we feature-test (if
appropriate, in the Windows world at least it seems more usual to test
at runtime).  This is based on the observation that these families
tend to be more different than similar.

There isn't a whole lot of uniformity here in libgcj.  In some places
we do try to unify things in other ways, e.g. the _Jv_platform macros
and functions.  In practice this heterogeneity doesn't seem to be a
big maintenance problem.

Tom