[ pmd-Bugs-631681 ] False +: Unused private field

[SourceForge.net]

Bugs item #631681, was opened at 2002-10-31 18:58
Message generated for change (Comment added) made by mnk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=479921&aid=631681&group_id=56262

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pmd
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tom Copeland (tomcopeland)
Assigned to: Nobody/Anonymous (nobody)
Summary: False +: Unused private field

Initial Comment:
public class Foo {

 public void bar() {
  Inner inner = new Inner();
  inner.innerFoo.buz();
 }

 private void buz() {}

 public class Inner {
  public Foo innerFoo;
 }
}

buz() is reported as unused.  Will symboltable be able
to fix this?

----------------------------------------------------------------------

Comment By: Mathias Nicolajsen Kjærgaard (mnk)
Date: 2009-08-16 22:27

Message:
If it is known that PMD produces false positives on the "unused private
field" check, and it cannot be fixed easily, why not remove the check from
the suite then?
I think most modern compilers reports these problems (correctly) now
anyways.

----------------------------------------------------------------------

Comment By: Wouter Zelle (wfzelle)
Date: 2007-10-16 13:04

Message:
Logged In: YES
user_id=555114
Originator: NO

To fix that case, you need to know the return value of getFoo. This
requires some advaned type resolution that is currently now available. So
I'm going to leave this one alone for now.

----------------------------------------------------------------------

Comment By: Wouter Zelle (wfzelle)
Date: 2007-10-15 13:48

Message:
Logged In: YES
user_id=555114
Originator: NO

Only this one is a real problem, the other cases have already been fixed:

public class Foo {
 private Foo fooField;

 public void bar() {
  Biz.getFoo().buz();
 }

 private void buz() {}
}

----------------------------------------------------------------------

Comment By: Wouter Zelle (wfzelle)
Date: 2007-10-10 12:50

Message:
Logged In: YES
user_id=555114
Originator: NO

I fixed the inner class examples for UnusedPrivateField. I will look at
UnusedPrivateMethod too.

----------------------------------------------------------------------

Comment By: Tom Copeland (tomcopeland)
Date: 2006-09-26 00:00

Message:
Logged In: YES
user_id=5159

Another case:

public class FilterConfigBean {
  private Filter m_filter;
  public void foo(FilterConfigBean configs) {
    for (FilterConfigBean config : configs.values()) {
      config.m_filter.init(config);
    }
  }
}


----------------------------------------------------------------------

Comment By: Tom Copeland (tomcopeland)
Date: 2005-02-02 17:20

Message:
Logged In: YES
user_id=5159

Another case from elharo:

=======================
 Try running PMD's unused code ruleset on the current
jaxen (http://jaxen.codehaus.org/) code base. It pops
up several issues that appear to all be false positives
with respect to inner classes. For instance consider
this code:

public class XPathFunctionContext extends
SimpleFunctionContext
{
/** Singleton implementation.
*/
private static class Singleton
{
/** Singleton instance.
*/
private static XPathFunctionContext instance =
new XPathFunctionContext();
}

/** Retrieve the singleton instance.
*
* @return the singleton instance
*/
public static FunctionContext getInstance()
{
return Singleton.instance;
}

PMD complains that the instance field in the Singleton
class is unused, but that isn't true. There appear to
be simialr issues with method invocations between outer
and inner classes.
=======================

Thanks!

Tom

----------------------------------------------------------------------

Comment By: Tom Copeland (tomcopeland)
Date: 2003-06-20 14:43

Message:
Logged In: YES
user_id=5159

Another variation on this theme:

 "Avoid unused private methods is wrong in the following
context:

public class Converter {
private final static Converter converter = new
Converter();

public void doSomething(String s) {
Converter.converter.doSomethingImpl(s);
}

private void doSomethingImpl(String s) {
// do something
}

}

----------------------------------------------------------------------

Comment By: Scott Oster (ostersc)
Date: 2003-05-15 18:08

Message:
Logged In: YES
user_id=273524

Same problem occurs for fields as for methods.

Scott

----------------------------------------------------------------------

Comment By: C. Lamont Gilbert (dnoyeb)
Date: 2003-02-15 03:39

Message:
Logged In: YES
user_id=280374

2 things.

1. this is beyond the current capabilities of PMD, so I
would not mark it as a bug but an RFE.

2.  I would err on the side of LESS hits, so I would mark
buz() as used.  This way as PMD improves it catches more
cases.  

Or perhaps their can be an overall PMD setting of vigorous
or cautious in which all Rules can either err on the side of
less misfires, or err on the side of more safety so to speak.

----------------------------------------------------------------------

Comment By: C. Lamont Gilbert (dnoyeb)
Date: 2003-02-07 04:52

Message:
Logged In: YES
user_id=280374

perhaps the code I have been working on will assist this.
it helps discern how methods are called.

----------------------------------------------------------------------

Comment By: Tom Copeland (tomcopeland)
Date: 2002-11-08 17:35

Message:
Logged In: YES
user_id=5159

Stefan Bodewig provided another example:

public class Foo {
 private static class Inner {
  private int bar;
 }
 public void buz() {
  Inner inner = new Inner();
  return inner.bar;
 }
}

This should be resolvable, but will take some work...

Tom

----------------------------------------------------------------------

Comment By: Tom Copeland (tomcopeland)
Date: 2002-11-01 15:31

Message:
Logged In: YES
user_id=5159

A simpler example:

public class Foo {
 private Foo fooField;
 public void bar() {
  Foo f = new Foo();
  f.fooField.buz();
 }
 private void buz() {}
}

The problem is a more general one of resolving expressions
and types.  This particular case could be solved by resolving
types within one compilation unit, but here's one that can't:

public class Foo {

 private Foo fooField;

 public void bar() {
  Biz.getFoo().buz();
 }

 private void buz() {}
}

Unless we go outside the compilation unit and figure out that
Biz.getFoo() returns a Foo, we'll miss this usage of the
private method.  Same goes for private fields, too.

So to catch these we need to do complete symbol resolution.

Tom


----------------------------------------------------------------------

Comment By: Tom Copeland (tomcopeland)
Date: 2002-11-01 01:44

Message:
Logged In: YES
user_id=5159

This one is really going to require some compilerish symbol
tracking.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=479921&aid=631681&group_id=56262

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Pmd-devel mailing list
Pmd-devel@...
https://lists.sourceforge.net/lists/listinfo/pmd-devel