On 11/23/06, Stefano Mazzocchi <[EMAIL PROTECTED]> 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/
