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)
_______________________________________________
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
