On 9/6/05, Jeroen Frijters <[EMAIL PROTECTED]> 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/ _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
