On 3/19/06, Stuart Ballard <stuart.a.ballard@xxxxxxxxx> wrote: > As far as I can figure out, an annotation is pretty much the only way > to get these kinds of methods to get flagged by Japi. Actually, I figured out (and implemented in Japi) a place where we can carry a flag on any method without requiring 1.5 at all. Adding an unchecked exception to the throws clause has absolutely no semantic effect (and Japi knows this and ignores them), but Japi can be (and has been) modified to pick up a particular exception and report based on it. I believe Classpath already has an unchecked NotImplementedException so that's what I used. Any method marked as "throws NotImplementedException" will be reported by Japi as "not implemented in Classpath", in the same category as "missing" errors. Any feedback on this approach is welcome, I'm certainly willing to modify it if people have any suggested improvements. Note that I'm not suggesting we just leave all stub methods around indiscriminately and use this trick on them; stub methods that aren't inherited from a superclass and can be removed without breaking compilation should just be removed. But for the ones we can't remove, we can now flag them. Obviously, the throws clause technique only works on methods and constructors, not fields or classes, but I don't think this is a big problem. There's not really any such thing as a "stub field" (it's either there or not) and any classes made up entirely of stubs should surely be removed anyway. If this approach is acceptable to everyone, the next question is how do we identify the stub methods to flag them? Obviously there's no reliable programmatic way but it seems like a program ought to be able to report possible candidates for a human to look through. I think any stub method would fall into one of these categories: A) Void method that does nothing at all or nothing but return; B) Method that unconditionally throws; C) Method that unconditionally calls superclass implementation of the same method with the same args; or D) Method that unconditionally returns a hardcoded constant, including null. Obviously detecting these things would give a lot of false positives, especially D, but I think it should catch all the stubs. Anyone know of a good tool that could produce a list of methods meeting these criteria? Stuart. -- http://sab39.dev.netreach.com/
