harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject 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 Fri, 24 Nov 2006 00:29:00 GMT
Stuart Ballard wrote:
> On 11/23/06, Stefano Mazzocchi <stefano@apache.org> 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.


View raw message