Re: jgss constant values

[Stuart Ballard]

On 9/6/05, Jeroen Frijters <address@hidden> wrote:
> > [1] like the "missing hashCode() method" reports in the jgss package,
> > which I'll look into...
> 
> IMO not a Japi bug. We're missing the hashCode() method in the
> interface. I don't think it's very relevant, but the idea is that
> because the interface explicitly declares the method, implementers are
> encouraged (but not required, of course) to override it.

I see where you're coming from but I disagree. As I said about jgss, I
believe that any time there's a japi error it indicates a real problem
that needs to be fixed; if not in Classpath then in japitools itself.
I've always erred on the side of only flagging errors when there's
absolutely no way it can be correct.

This can lead to failing to report things that might actually be
considered a problem - such as if we didn't implement an override of
equals() or hashCode() on a class that actually needs it - but I think
it's more important to avoid false positives. Theoretically, the class
that doesn't implement equals() or hashCode() might be just fine
because it's handled by an "if (this instanceof Whatever)" in
java.lang.Object.equals(). That's obviously an extreme (not to mention
silly) example, but the general principle of only testing for real
errors rather than implementation details is one that's guided a lot
of japitools decisions.

The way I see it, including equals() and hashCode() in an interface
has absolutely no effect whatsoever on behavior, so implementors are
free to decide to save those few bytes in the classfile - just like
Classpath has a policy of not declaring RuntimeExceptions that can be
thrown, because it's redundant. Japitools shouldn't flag that decision
as an error, because it's not.

Stuart.
-- 
http://sab39.dev.netreach.com/