propose to rename natPlainSocketImpl to natPosixPlainSocketImpl

Tom Tromey
Fri Feb 1 23:32:00 GMT 2002

>>>>> "Adam" == Adam Megacz <> writes:

Adam> Okay, I've proposed the two simple extremes (group by
Adam> functionality, group by platform), and both have been
Adam> rejected. If we're going for a middle ground, I'll just start
Adam> submitting patches and let people comment on stuff on a case by
Adam> case basis; I guess my goal of having a simple, uniform naming
Adam> scheme for port-specific stuff is not going to happen.

I think what Bryce (apologies if I'm misrepresenting him) and I were
getting at was something like this:

* Have a separate (e.g.) natFile<Platform>.cc for each OS family.
  So for instance we'd have one for all Posixy
  systems, and in that file we'd account for particular oddities using
  #ifdef.  There are several files for which we'd do this; I think
  you've already listed them.
  The rationale here is that putting all the code in a single file
  results in a huge mess of #ifdef.

* Look in existing files for seemingly generic code which is really
  platform-specific.  Some is in and some in;
  there might be a little more scattered about.  For this code, define
  a simple OS API and move the code behind it.

One question is, what's our goal?  I think the goal is to have a
system which is relatively easy to understand both for maintenance and
for new ports.  Right now there is stuff all over.  You have to know
to dig through to add weird things for a new port.  You
probably wonder "what is and do I need one?", or "should this
function go in, or just inline in".  Etc.

With the above proposal, we'd have a small list of files you'd need to
rewrite for each new port.  Since they'd all be named similarly, you
could construct a list using `find'.  For clean platforms you'd have
the benefit of working using files without ugly #if code.

I'm not really sure what to do about the ConcreteProcess code.  The
trend has been to move such code (non-public classes) out of java.lang
and into gnu.gcj (or if it is shared with Classpath).

Another approach would be to define a more complete OS API and then
have a single (e.g.) which used the abstract API.  I think
this would be more work, and perhaps harder to maintain, but I don't
have any real objection to it.

What do you think of this?


More information about the Java mailing list