propose to rename natPlainSocketImpl to natPosixPlainSocketImpl

[Adam Megacz]

I hesitate to comment on this, since I'm still a newbie here, and this
is an architectural issue... feel free to yell at me if I'm wrong...


Tom Tromey <tromey@redhat.com> writes:
> I think it would be nice to think up a naming scheme that we can use
> for this stuff.

Here are the files that need to be diverted on a per-OS basis (stuff
with * in it already acts this way):

  java/net/natInetAddress.cc
  java/net/natPlainDatagramSocketImpl.cc
  java/net/natPlainSocketImpl.cc
  java/lang/nat*Process.cc
  java/io/natFile*.cc
  java/io/natFileDescriptor*.cc

As you can see, the naming is all wacko. Some files put the platform
name in the middle of the filename. Some of them put it at the
end. Sometimes Ecos == Posix. Sometimes it doesn't. There's a ton of
duplicated code. Sometimes only the natXXX.cc file differs. Sometimes
the .java file differs to (I think these can and should be eliminated).


> Ideally for natSystem.cc and perhaps prims.cc we would have some kind
> of platform API, just like we have a thread API and a GC API.  Then
> the platform-specific code can be segregated somewhere.

Definately.

What do you all think of merging all the platform-specific files into
a single natXXX.cc file per class, and a single .java file per class,
using #ifdefs for platform-specific stuff.

As far as I can tell, the code overlap rules aren't too simple. If you
force each platform to have a seperate file, you wind up with a lot of
code duplication. By keeping all the code for java.io.File in one
place, you can use #ifdefs to control code sharing -- sometimes Win32
and POSIX use the same code, other times they don't.

This would also let us do away with the symlinking stuff, so builds
would work on platforms without symlinks.


> The current scheme is almost ok.  One thing I'd like to see is the
> ability to set the "OS flavor" differently in different situations.
> E.g., we might generally want "Posix" but then use "None" for java.net
> in some circumstance.

How about 'configure --disable-networking'?

  - a