Re: Japize fix

[Robert Schuster]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Roman,
I had a similar question some months ago. It all lead to this[0] issue
in the mediation wiki.

[0] -
http://developer.classpath.org/mediation/ClasspathFirstSteps#head-9467fcae64fe2b7fa060dd0b5e1378bb6b028a64

cu
robert

Stuart Ballard wrote:
> [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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCi7jbG9cfwmwwEtoRAqocAJ9AYAUlB1NYG98j0jpdKhTeaKekaQCgm/Zo
nT0kJcssgH6wqfUSD1/9xwE=
=z88H
-----END PGP SIGNATURE-----