GRECLIPSE

Java search for references to getter returns references to corresponding field

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.6.0.Release
  • Fix Version/s: 2.6.1.Release
  • Component/s: Search
  • Labels:
    None
  • Number of attachments :
    0

Description

Open a project with Groovy nature, open a Java source file, right-click a getter method, say, getFoo(), click References - Workspace.

Actual: The search view lists references to the method getFoo() as well as references to the corresponding field foo.

Expected: Only references to the actual method should be listed. References to the field should not be listed.

Workaround: Remove Groovy nature from project and repeat search. Search will revert to expected behavior.

I believe this has to do with the plugin now being able to search for synthetic accessors. But this is a Java file and the plugin should stay the heck out of that.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrew Eisenberg added a comment -

That shouldn't be.

Show
Andrew Eisenberg added a comment - That shouldn't be.
Hide
Permalink
Andrew Eisenberg added a comment -

A little more clarification. Here is what we need to ensure:

Scenario 1:

Groovy:
class G {
  int yyy
}

Java: 
class J {
  void meth() {
    new G().getYyy();
    new G().yyy = 0;  // an error, but still refers to the field in G
  }
}

Reference to getYyy and yyy should be resolved to the declaration.

Scenario 2:

Groovy:
class G {
  public int yyy
}

Java: 
class J {
  void meth() {
    new G().getYyy();  // an error, but still refers to the field in G
    new G().yyy = 0;
  }
}

Same. Reference to getYyy and yyy should be resolved to the declaration.

Scenario 3:

Groovy:
new J().nuthin
new J().getNuthin()

Java: 
class J {
  public int getNuthin() {return 0;}
}

Reference to getNuthin and nuthin should be resolved to the declaration.

Scenario 4:

Groovy:
new J().nuthin
new J().getNuthin()

Java: 
class J {
  public int nuthin;
}

Reference to nuthin is resolved but getNuthin is not.

Scenario 5:

Groovy:
empty

Java: 
class J {
  public int nuthin;
  void foo() {
    new J().nuthin
    new J().getNuthin()
  }

Reference to nuthin is resolved but getNuthin is not.

Show
Andrew Eisenberg added a comment - A little more clarification. Here is what we need to ensure: Scenario 1: Groovy: class G { int yyy } Java: class J { void meth() { new G().getYyy(); new G().yyy = 0; // an error, but still refers to the field in G } } Reference to getYyy and yyy should be resolved to the declaration. Scenario 2: Groovy: class G { public int yyy } Java: class J { void meth() { new G().getYyy(); // an error, but still refers to the field in G new G().yyy = 0; } } Same. Reference to getYyy and yyy should be resolved to the declaration. Scenario 3: Groovy: new J().nuthin new J().getNuthin() Java: class J { public int getNuthin() { return 0;} } Reference to getNuthin and nuthin should be resolved to the declaration. Scenario 4: Groovy: new J().nuthin new J().getNuthin() Java: class J { public int nuthin; } Reference to nuthin is resolved but getNuthin is not. Scenario 5: Groovy: empty Java: class J { public int nuthin; void foo() { new J().nuthin new J().getNuthin() } Reference to nuthin is resolved but getNuthin is not.
Hide
Permalink
Andrew Eisenberg added a comment -

To be clear, the problem described in this bug is that scenario 3 is matching in Java, but it should only be matching in Groovy.

Show
Andrew Eisenberg added a comment - To be clear, the problem described in this bug is that scenario 3 is matching in Java, but it should only be matching in Groovy.
Hide
Permalink
Andrew Eisenberg added a comment -

Fix is committed with regression tests.

Show
Andrew Eisenberg added a comment - Fix is committed with regression tests.
Hide
Permalink
Hannes Schmidt added a comment -

That was fast. Very cool, thanks!

Show
Hannes Schmidt added a comment - That was fast. Very cool, thanks!
Hide
Permalink
Andrew Eisenberg added a comment -

I raised the priority to critical because Groovy-Eclipse should not be affecting the results of pure Java code. However, the fix is not available in a dev build yet since we are having test failures on the build server.

Show
Andrew Eisenberg added a comment - I raised the priority to critical because Groovy-Eclipse should not be affecting the results of pure Java code. However, the fix is not available in a dev build yet since we are having test failures on the build server.
Hide
Permalink
Andrew Eisenberg added a comment -

I raised the priority to critical because Groovy-Eclipse should not be affecting the results of pure Java code. However, the fix is not available in a dev build yet since we are having test failures on the build server.

Show
Andrew Eisenberg added a comment - I raised the priority to critical because Groovy-Eclipse should not be affecting the results of pure Java code. However, the fix is not available in a dev build yet since we are having test failures on the build server.

People

  • Assignee:
    Andrew Eisenberg
    Reporter:
    Hannes Schmidt
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: