classpath
[Top][All Lists]
Advanced

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

Re: equals() implementation not shown by JAPITools


From: Stuart Ballard
Subject: Re: equals() implementation not shown by JAPITools
Date: Mon, 08 Nov 2004 09:05:23 -0500
User-agent: Mozilla Thunderbird 0.8 (X11/20040926)

Jeroen Frijters wrote:
Hmm. I think this is by design, but I can see your point, it would be
nice if Japitools had a switch that was able to detect these
differences.

You're right that this is by design, because there's no way to indicate reliably whether this scenario is a problem or not. There are plenty of cases where the decision of whether to override an inherited method has no bearing on correctness at all. In numerous places in the Collections architecture it's done solely for performance, for example.

I specifically don't want japitools to get into the business of testing implementation details rather than the public API. And technically it's an implementation detail that Object.equals() doesn't contain a bunch of instanceof tests with specific implementations for the classes that would otherwise need customized equals() implementations.

As another example of why this is an implementation detail, think about this (theoretical) scenario: an abstract superclass with no public or protected constructors (so that all subclasses must be provided within the class library) and a couple of subclasses. Maybe Sun's implementation provides equals() implementations in each of the subclasses but they do the same thing, relying only on information that's available in the superclass. Classpath should be free to implement its version more intelligently, by putting the equals() method in the superclass and not defining it in the subclasses at all.

I'd suggest that the solution here would be to scan Sun's javadoc[1] for classes with custom equals() methods and write Mauve tests for the correct *behavior* of equals, rather than the implementation. There might well be an opening for a special tool to do this automatically, but I don't see it as an API compatibility issue, so I think it's outside japitools' scope.

Thoughts?

Stuart.

[1] While I believe it's definitely legal to be scanning Sun's jar files for public API information as japize does, scanning the jar files for an implementation detail strikes me as slightly more questionable, so I suggest scanning the javadoc instead.


--
Stuart Ballard, Senior Web Developer
NetReach, Inc.
(215) 283-2300, ext. 126
http://www.netreach.com/




reply via email to

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