On Mon, 20 Mar 2006 09:15:41 -0500 "Stuart Ballard" <[EMAIL PROTECTED]> wrote:
> On 3/19/06, Stuart Ballard <[EMAIL PROTECTED]> 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. > It sounds like a bad hack on the JAPI side, but it's up to you if you're maintaining this. I can't currently find NotImplementedException in Classpath outside the new jdwp code, but I may be missing something. If we have a gnu.classpath.NotImplementedException, then we could catch this specifically in JAPI, and also output a nice message. The immediate problem I see (and why we don't generally use an exception) is that the problem can still continue with an exception, whereas it can't with an error. > Any feedback on this approach is welcome, I'm certainly willing to > modify it if people have any suggested improvements. > The main problem I can foresee is actually finding all the code and putting this in... > 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. > Agreed; I think this should be a last resort course of action. > 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? > There are some FIXMEs in the code that would also help, but I think it has to be a largely manual process starting with a grep of the source for FIXMEs and then checking likely candidates (there are obviously some classes that are fully or largely implemented). This seems like another case of reviewing code that is going to become more prominent as Classpath matures to a largely implemented codebase. The same really needs to be done for documentation and security. > Stuart. > -- > http://sab39.dev.netreach.com/ > Cheers, -- Andrew :-) Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments. See http://www.fsf.org/philosophy/no-word-attachments.html Support OpenDocument instead. Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html public class gcj extends Freedom implements Java { ... } "Value your freedom, or you will lose it, teaches history. `Don't bother us with politics' respond those who don't want to learn." -- Richard Stallman The views expressed above are representative of my own personal opinions, and not necessarily those of the University of Sheffield.
pgpQEM3zGaNgv.pgp
Description: PGP signature
