[cp-patches] Patch: FYI: implement NumericShaper

Stuart Ballard stuart.a.ballard at gmail.com
Mon Mar 20 14:15:41 UTC 2006


On 3/19/06, Stuart Ballard <stuart.a.ballard at gmail.com> 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/



More information about the Classpath-patches mailing list