Re: PATCH for java.nio FileChannel and MappedByteBuffer

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

Tom> I still don't like this.  I read through your objections, but
Tom> bluntly I find them all a bit theoretical.  We've been using the
Tom> current system for 4 years without serious problems.

Per> Using include files *is* the standard approach in the GNU toolchain.

In general we have different needs from the rest of gcc.  For
instance, no other target library deals with sockets.

Per> Trying to divide the universe of targets into "Posix", "Win32",
Per> and "Ecos" seems so obviously wrong to me, I don't understand
Per> why you with your experience is in favor it.

First, there is some bit-rot in here.  The "Ecos" port was never
really done in a complete way, and as far as I know nobody uses it as
an Ecos port any more.  It is more of a placeholder for a "do nothing"
port where networking, etc, don't work.  I'm not sure if we can remove
it, I think Anthony would know; parts of it might be used for newlib
ports.

The reason I don't see anything really wrong with our approach is that
it models reality reasonably well enough.  We treat all Unixy systems
alike, under the "POSIX" flavor.  And we treat Windows as something
different, which it is.  Within a flavor we may choose to do feature
tests (we do for Unix), or not (we don't for Windows) as appropriate
for that platform type.

A hypothetical Cygwin port might or might not need to share bits from
one or both of the Unix and Windows ports.  That's a lot of "if",
though -- nobody is working on or has expressed any real interest in
such a port.  Should someone start work on it, we can address the
problems that arise when they do arise.

Per> I can imagine you'd might want to use Gtk graphics on Win32.

The AWT peers don't fall into this part of the configury framework at
all.  We basically only do this for OS facilities like I/O.  Threads
are handled in a vaguely similar way, as is the GC interface (though
in that case the selector is not the platform).

Again, in practice this works ok.  I can't think of a problem reported
that related to the symlinks.

Per> We'd need natMappedByteBufferOldMac.cc, but it would be identical
Per> to natMappedByteBufferEcos.cc, which is silly.

Well, we wouldn't do that.  For instance we would introduce a new
variable in configure that would default to $PLATFORM but which would
be set to `Ecos' or `Null' or whatever on `OldMac'.

Suppose we do a cpp-based implementation.  Then we need some way to
select between variants.  I.e., a configure-defined macro that tells
us which .cc file to include.  Well, any way we can define that macro,
we can also define a shell variable to set up the symlink.

Per> But new classes should
Per> avoid symlinks, and removing the existing symlinks would be a
Per> useful though low-priority cleanup.

This leads to the gcc maintenance problem that Zack pointed out in his
gcc summit paper: half-finished conversions.  I've come to realize we
only rarely do cleanups :-(

Tom