[Top][All Lists]
[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.