I was browsing around the japi results today and I noticed errors for a number of constants in the org.ietf.jgss.GSSException class. Aha, I thought, low-hanging fruit, maybe I should make a patch. But when I looked at the source I saw this comment:
// These values do not jive with the "Constant Field Values" in the J2SE // 1.4.1, but do follow RFC 2853. I trust the IETF, but not Sun. I wanted to at least raise the question as to whether this is the right approach here. It seems clear that Sun made a mistake in assigning these values in the JDK, but I'm not sure how helpful it is for Classpath to "correct" this mistake unilaterally. I'm concerned because these values, of course, actually get compiled into the binaries of classes that are built against a particular set of libraries. Code compiled against the JDK but run with Classpath will disagree with Classpath about the values of these constants; the same with code compiled against Classpath but run against the JDK. And if you try to combine code compiled against the JDK with code compiled against Classpath, they won't agree regardless of how you run them. Of course from a personal point of view I also dislike anything which amounts to deliberate japi errors, but really that's because I think that any japi error (except for the ones resulting from bugs in japitools[1]) is an indication of a real problem anyway. I'm not disputing the fact that it would be good for Classpath to try to fix Sun's error here, but I'm not sure that this is the way to do it. I know nothing about GSS (I don't even know what it stands for ;) ) but if these error numbers come from some kind of protocol, perhaps we could translate the "real" error code to the incorrect Sun constant under the hood instead? Does the Classpath project have an explicit policy for these kinds of situations? Stuart. [1] like the "missing hashCode() method" reports in the jgss package, which I'll look into... -- http://sab39.dev.netreach.com/ _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
