[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Japize fix

From: Robert Schuster
Subject: Re: Japize fix
Date: Wed, 18 May 2005 23:51:23 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.7.8) Gecko/20050514

Hash: SHA1

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

[0] -


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.
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]