RFC: Moving native code in java.net into architecture dependant files

[Mohan Embar]

Michael,

>Here is a patch which moves the native code of java.net into
>architecture dependant files for better/easier maintaining, as
>requested by several people.

To my untrained eyes, this looks nice. I'm especially eager to have this in place
so we can sort out things like the strerror() stuff being broken in Win32. Ranjit,
do you agree with me that even if the Win32 code isn't perfect, we can sort things
out once the split has been made?

I have a couple of comments. Please let me know if I've misunderstood something
or gotten the facts wrong:

- Is it a done deal that all eCos variants will never have any net code in them? If
  not, the naming conventions seem to establish the equivalence between
  the eCos platform and java.net functionality being disabled. Is this confusing
  from a naming standpoint? What if instead of natInetAddressEcos.cc (for example),
  you had natInetAddressNoNet.cc and made another variable called NET_PLATFORM
  which factored in not only PLATFORM, but also whether enable_java_net was "no"?

>Question: Is it useful to point to "ecos" for the native java.net code
>when DISABLE_JAVA_NET is defined ? This would make the code in the
>"posix" target a little bit clearer. Any ideas for this ?

- This would clean up the Win32 target too. If you did what I previously mentioned, you
  could safely eliminate the duplicate code within the #ifdef DISABLE_JAVA_NET...#endif
  sections of the Posix and Win32 files because

  AC_LINK_FILES(java/net/natInetAddress${NET_PLATFORM}.cc, java/lang/natInetAddress.cc)

  would have NET_PLATFORM=NoNet when say PLATFORM=Win32 and enable_java_net was
  "no".

Does this make any sense or have I not understood things correctly?

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/