japitools-list
[Top][All Lists]
Advanced

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

[Japi] Re: svn commit: r478620 [2/2] - in /harmony/enhanced/classlib/tru


From: Stefano Mazzocchi
Subject: [Japi] Re: svn commit: r478620 [2/2] - in /harmony/enhanced/classlib/trunk/modules/swing: META-INF/MANIFEST.MF src/main/java/common/javax/swing/JTable.java
Date: Thu, 23 Nov 2006 16:29:00 -0800
User-agent: Thunderbird 1.5.0.8 (Macintosh/20061025)

Stuart Ballard wrote:
> On 11/23/06, Stefano Mazzocchi <address@hidden> wrote:
>> Tim Ellison wrote:
>> > Nathan, I think you have to change the method signature to, for
>> example,
>> >
>> > public void setAccessibleName(String s) throws
>> NotImplementedException {
>> >     throw new NotImplementedException();
>> > }
>> >
>> > for Japi to recognize it.
>>
>> Are you sure? that seems wrong as it would alter the API signature.
> 
> Tim is correct. Japi doesn't attempt to look at the bytecode body of
> methods, only the signatures. However, a subclass of RuntimeException
> has no practical effect on the API because any RuntimeException can be
> thrown at any time by any method. Japi will already ignore any
> differences due to RuntimeExceptions in the throws clause (it'll also
> treat, eg, "throws IOException, FileNotFoundException" as identical to
> "throws IOException").
> 
> Ignoring RuntimeExceptions in throws clauses was a decision made in
> Japitools as a result of realizing that different implementations
> might decide that either (a) it's a good idea to add every possible
> throw in the throws clause for documentation purposes, or (b) adding
> redundant stuff to throws clauses is just a waste of bytecode for no
> good reason, or (c) some hybrid between the two, and any of those
> decisions are simply implementation details and don't cause any
> problems for API compatibility. So Japitools shouldn't penalize any of
> those decisions even if the API being compared to made a different
> decision.
> 
> In the case of NotImplementedException it's moot for another reason as
> well: the whole point of adding it in the first place is that the API
> *isn't* compatible yet, because it doesn't *work*. Even if you *did*
> decide to consider it an incompatible change, an incompatible
> signature is the least of your worries on a method that isn't
> implemented at all ;)

Good points, I stand corrected.

-- 
Stefano.





reply via email to

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