jgss constant values

[Stuart Ballard]

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/