theUser BL wrote:
And in which part is the GNU Classpath implementation better then Suns implementation? (from the technical point of view, not from the license side) ?
You might like to look at http://builder.classpath.org/xml/SAXTest/ which shows the XML SAX API conformance status of the GNU implementation versus Xerces (the parser redistributed by Sun).
Until today GNU Classpath makes sence, because it is an OpenSource Java-implementation and Suns Java isn't OpenSource. And it is not only a Java-implementation it is in parts a rewrite of Suns Java. As i know, there is nowhere defined in any book how the ocean-theme looks like. Only the old metal theme is defined at http://java.sun.com/products/jlf/ So in parts GNU Classpath is not only a implementation of what the JCP defines, its a rewrite of that, what Suns have done.
Yes. This vexes me greatly, when there is pressure from the community to reproduce a bug-for-bug compatible class library, i.e. that we should try to code to match Sun's implementation instead of coding a good, bug-free implementation of the specification. But, as you point out, in many cases the specification is vague or nonexistent, and people just want it to work and don't care about specs.
But until Sun makes its Java implementation OpenSource, then the situation is different.
No, I don't think so.
So I think, that - if Sun makes its Java OpenSource - it would be a bad thing, if then GNU Classpath and Apache Harmony still exists.
So, given that NetBSD exists, is it a bad thing that Linux and OpenSolaris and the Hurd exist? After all it was around long before these upstarts. Surely we should all be working on the One True Operating System™?
-- 犬 Chris Burdess "They that can give up essential liberty to obtain a little safety deserve neither liberty nor safety." - Benjamin Franklin
Attachment:
PGP.sig
Description: This is a digitally signed message part
