Re: Japize fix

[Stuart Ballard]

[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 <address@hidden> 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/