Eclipse - plugin to find unused CLASS MEMBER VARIABLES?

Discussion in 'Java' started by steve.chambers@gmail.com, Nov 2, 2005.

  1. Guest

    I've recently been looking for some tools to help partly automate a
    pretty labourious process of doing a big batch of code reviews. Very
    happy with the ones I've found so far (PMD, CheckStyle and an obscure
    plugin to find unused classes at http://seessle.de/dclj/de.seessle.
    eclipse tools.zip ). Would recommend them to anyone! :)

    But there's one thing that none of them seem to do - find public or
    protected class member variables that aren't used within the whole
    project. (The nearest to donig this is that PMD will find variables
    that are declared within a particular class but not used in it - but
    this isn't quite what I want as there seem to be quite a few constants
    that aren't referenced anywhere within the project).

    Does anyone know if such a tool exists, ideally for eclipse but if none
    exists then I'd consider using a non-eclipse based one...

    Thanks for any help / suggestions....

    Cheers,
    Steve
     
    , Nov 2, 2005
    #1
    1. Advertising

  2. Chris Uppal Guest

    wrote:

    > But there's one thing that none of them seem to do - find public or
    > protected class member variables that aren't used within the whole
    > project. (The nearest to donig this is that PMD will find variables
    > that are declared within a particular class but not used in it - but
    > this isn't quite what I want as there seem to be quite a few constants
    > that aren't referenced anywhere within the project).


    I don't know of any such tool personally, but try looking for whole-program
    optimisers, which often detect such cases. You may or may not be able to
    persuade one to list the stuff it removes. Also check out obfuscators which
    (AFAIK) quite often do the same kinds of optimisation.

    Or I could write one for you if you liked, but it'd co$$$t you ;-)

    BTW, you won't be able to find unused constants (by which I take it you mean
    static final int/bool/String fields initialised to constant values), since uses
    of such fields are inlined by the compiler and so would all show up as "unused"
    by any byte-code-level analyser. You may be able to find a source-level
    analyser that would do the job, but I wouldn't say much for your chances of
    finding one that works well since source-level analysis is /much/ harder than
    bytecode level (especially since Java5). Probably the easiest thing is just
    to comment-out any suspicious constant and see if the build breaks...

    -- chris
     
    Chris Uppal, Nov 2, 2005
    #2
    1. Advertising

  3. Guest

    Cheers for the quick reply Chris. Will have a look for an obfuscator.
    As for writing one, unfortunately I'm a lowly programmer in this
    company and am pretty sure I wouldn't be able to convince them to spend
    anything (they're trying to use free stuff where possible, hence the
    tools I've mentioned :). Maybe my best bet is manually go through them
    all using Eclipse's references finder on each constant to find out
    whether it's used or not in the project or workspace.

    Best regards,
    Steve
     
    , Nov 2, 2005
    #3
  4. Rhino Guest

    <> wrote in message
    news:...
    > Cheers for the quick reply Chris. Will have a look for an obfuscator.
    > As for writing one, unfortunately I'm a lowly programmer in this
    > company and am pretty sure I wouldn't be able to convince them to spend
    > anything (they're trying to use free stuff where possible, hence the
    > tools I've mentioned :). Maybe my best bet is manually go through them
    > all using Eclipse's references finder on each constant to find out
    > whether it's used or not in the project or workspace.
    >

    Actually, Chris's approach may be faster: just comment out every variable
    you're not sure is being used and then see if the code will compile. Then
    uncomment everything that raises an error message. When you finally get a
    clean compile, you know you've got all the variables that are being used.
    Then, go through your source and delete all those commented variables.

    This is still likely to be a time-consuming process if you have many classes
    and many suspect variables but it may still be cheaper than writing
    something which does the same thing. Or not.

    Rhino
     
    Rhino, Nov 2, 2005
    #4
  5. Roedy Green Guest

    On 2 Nov 2005 04:26:38 -0800, wrote, quoted
    or indirectly quoted someone who said :

    >Maybe my best bet is manually go through them
    >all using Eclipse's references finder on each constant to find out
    >whether it's used or not in the project or workspace.


    Another approach would work this.

    You use a class file library (see
    http://mindprod.com/jgloss/jasm.html) to parse all the class files for
    references and definitions and squirt them into a flat file to sort
    alphabetically by fully qualified signature name and dedup.

    Now look for definitions without references or vice versa and research
    them.

    You might need an external sort to deal with the volume. See
    http://mindprod.com/jgloss/sort.html
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Nov 2, 2005
    #5
  6. Chris Smith Guest

    Chris Uppal <-THIS.org> wrote:
    > BTW, you won't be able to find unused constants (by which I take it you mean
    > static final int/bool/String fields initialised to constant values), since uses
    > of such fields are inlined by the compiler and so would all show up as "unused"
    > by any byte-code-level analyser. You may be able to find a source-level
    > analyser that would do the job, but I wouldn't say much for your chances of
    > finding one that works well since source-level analysis is /much/ harder than
    > bytecode level (especially since Java5).


    It's worth noting that, in the context of an Eclipse plugin, you have
    access to the Eclipse JDT's parse tree representation of the source
    code. That makes this considerably easier than it might seem. I don't
    know if you can programmatically invoke the References->In Workspace
    function... but if so, then the requested plugin becomes almost trivial
    to write.

    So, just saying that it might not be as difficult as it sounds to write
    this things from scratch, because Eclipse has most of the tools that you
    need.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Nov 2, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page