Aicas again

[Casey Marshall]

I see that lots of things in the native parts of Classpath have been  
changing again, with what seems to present itself as a "portable"  
native layer.

I have some specific problems with this, in that it doesn't work on  
Darwin. In particular:

  - Darwin does not have MSG_NOSIGNAL.
  - VMTimeZone is broken, because it doesn't link to the target- 
generic object that implements the method (I saw traffic about this,  
so it may be fixed).

But in general, I do not appreciate what Aicas has been doing nor do  
I find it valuable. All I see this work doing is making Classpath's  
native implementation of things less and less maintainable, with a  
benefit that is utterly unclear to me. For GNU projects, the way to  
write "portable" native code is to cut your way as close as possible  
to something like POSIX, then use autoconf macros to tell which bits  
diverge. For most UNIXy systems, that should suffice. Writing native  
implementations for vastly different platforms -- like Windows --  
should mean writing a completely different native library.

The VM* classes already provide much of the abstraction you need for  
doing this; why have another layer that that introduces verbose, hard- 
to-analyze macros? I guess the answer is supposed to be "it makes it  
portable," but I don't see it. Also, while it promises portability,  
so far it has not delivered it, for one because it seems like these  
changes are never tested on platforms and VMs that most of us use.

I vote that they stop changing the native libraries of Classpath  
immediately, and that we come up with a sensible, straightforward way  
of writing default implementations for methods that need native  
support. Practically, we are targeting GNU/Linux and BSD (and  
probably Darwin; I know a few Classpath hackers use OS X, so we'd  
like it to run there, too) above all else; especially above whatever  
weird platforms Aicas is writing JamaicaVM for.

I've complained about this before, and the answer to that was  
basically complaining that because it's a contribution (by a company!  
For free and all that!), it shouldn't be criticized, because  
otherwise they'd rather not contribute it. That's not what I want at  
all; I would like to work with them to come up with something that  
all of us will be satisfied with (and that may not happen; if not,  
then Aicas is on their own for the native bits, and the community on  
its own), but what is going in now is ugly, unmaintainable, bad, and  
ultimately of no value to me. Code that I wrote   
(FileChannelImpl.lock) has changed, and I dislike it; a  
straightforward implementation that would work should work on most  
UNIXes that have fcntl has been obfuscated for no discernible reason.

I'm not trying to sound mean here; I honestly want us to evaluate  
this, and use or replace it based on its merits. Especially if this  
goes against GNU's standard practices, it should be criticized for that.

(Lastly, I apologize if what is happening now was proposed and OK'd  
by the community before; I am just looking at the result, and I don't  
like the result)