Tom Tromey <[EMAIL PROTECTED]> writes: > Short form: this particular japi note is probably a japi bug. And, > this patch doesn't actually change anything of note... interfaces > already implicitly inherit hashCode from Object (there is a special > case in the JLS for certain methods of Object).
CVS japi (http://www.kaffe.org/~stuart/japi/htmlout/cvs/h-jdk14-classpath.html) already excludes this error, and others like fields and methods whose types are inaccessible (javax.naming anyone?) I'm beginning to think I ought to drop the "regular" japi runs and just use the CVS ones for everything. Only problem with that is that if some checkin causes regressions in CVS japi we won't have good results for however long it takes to spot and fix. Also I haven't comprehensively compared the results against what the older version reported to be sure that there aren't any regressions already. But I guess there's a tradeoff of "possible unknown regressions" versus "definite known bugfixes" :) > I don't think that this patch hurts anything either. Now that it is > in I'd prefer it remain, if for no other reason than to placate japi. Japi was placated already :) But having these in place does serve a documentation purpose, as it reminds implementors that they have to override the hashCode. It also provides a place to hang javadocs describing what the algorithm should actually be (I don't know whether that applies in this case, though). > (FWIW I still want to see those RCSId patches go in as well...) Me too! Stuart. _______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
