[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

[Stuart Ballard]

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 ;)

Stuart.
--
http://sab39.netreach.com/