[hope you don't mind that I CC'd the classpath list. This is something of an FAQ so others may be interested in the answer]
On 5/17/05, Roman Kennke <[EMAIL PROTECTED]> wrote: > Hi Stuart, > > I have found what I think is a bug in Japize. If a method/field that is > declared in class A and that is derived in class B, but should be > overridden in class B (but is not), then this is silently ignored. Thanks for the suggestion and the patch. I'm afraid I won't be applying it though, because the behavior you describe is by design. Japize and japicompat specifically test for binary compatibility, and the rules of binary compatibility in Java are very clear that this kind of change is permitted. There's a good reason for it, regardless. The problem is that it's impossible to *know* whether the method should be overridden in class B. This is entirely an implementation decision that has no bearing on whether it accurately implements the same API or not. To give a concrete example: Last time I checked, the JDK did not override the subList method in LinkedList. By not overriding that method, they cannot be caching the starting and ending nodes of the sublist, which means that every access of the sublist is guaranteed to have to walk all the way up the original list until the start of the sublist is reached. If we were to try to enforce the rule that all the same methods should be overridden all in the same places, we'd be guaranteeing that Classpath had the same performance problem as the JDK in this area, when fixing it would have absolutely no impact on compatibility. Another scenario would be if there were stale code in the JDK in which an overridden method did exactly the same thing as the superclass method. (Don't try to convince me that there isn't crappy code in the JDK ;) ). Surely you don't want to enforce that Classpath must also have this stale code? That's skating dangerously close to copyright infringement - copying the implementation rather than the behavior. Whether to override or not is an implementation decision, not an API compatibility one. Japitools only tests for API compatibility. The right way to test this kind of thing is to write Mauve tests which test the *behavior* of the overridden method to confirm that in cases where it should be different from the superclass version, it really is. It might be possible to use your modified version of Japitools to provide a report of all such cases as a starting point to decide which methods to write tests for. Stuart. -- http://sab39.dev.netreach.com/ _______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath