Bug 119552

Summary: Clean/Build erroneously flags an error in code where none exists.
Product: [Eclipse Project] JDT Reporter: JD Anderson <wapadomo>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: P3 CC: Darin_Swanson
Version: 3.1.1Keywords: needinfo
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description JD Anderson CLA 2005-12-06 22:02:34 EST
The normal error checking shows no errors until the project is cleaned or rebuilt. Adding a harmless comment and then saving appears to clear the error until another build is attempted.

The code compiles and runs from the command line.

I have isolated the bug down to two interfaces and one class.

Parent.java

package bug;

public interface Parent
{

  public Integer bar();
  
}


Child.java

package bug;

public interface Child extends Parent
{
  
  public static final Child DEFAULT = new Child()
  {
    
    public final Integer bar() { return y; }
        
    int x = 0;
    
    private final Integer y = new Integer(0);
        
  };
  
// I have reduced my code down to the most simple example that will still
// reproduce the bug. In isolating the code I discovered a few oddities
// that may useful to the debugger.
//
// Oddity Number One:
// Originally x was used in the construction of y and both objects were
// fairly complex. I discovered that using Integer or a String for y
// and ignoring x completely would replicate the problem so I was able to
// spare you most of my boring code. But, when I tried to remove x the
// example would no longer reproduce the problem.
  
/*
  public static final Child DEFAULT1 = new Child()
  {
    
    public final Integer bar() { return y; }
            
    private final Integer y = new Integer(0);
        
  };  
*/
  
// Oddity Number Two:
// I wanted to put the example of oddity number one in the code,
// uncommented, to demonstrate that it would not reproduce the problem
// but the fragment above would. That would have been to easy. Putting
// the later fragment in hid the original problem once again. Curious as
// I was, I had to see if anything else would have the same effect. Yup.
  
/*
  public static final int z = 0;
*/

}


Test.java

package bug;

public class Test
{

  public Test()
  {
    a = Child.DEFAULT;
  }
  
  public final Child a;
}


Both of the oddities described in the comments of the Child interface can serve as work arounds so I guess this might not be a show stopper but it cost me a day.


wapadomo
Comment 1 Darin Swanson CLA 2005-12-07 00:58:58 EST
I do not believe you meant to file this against the Eclipse Ant support...I do not see the relevance?

Moving to JDT Core
Comment 2 Olivier Thomann CLA 2006-10-10 14:05:09 EDT
Could not reproduce with HEAD.
Could you please let us know if you can reproduce with either 3.2.1 or 3.3 integration builds?
Thanks.
Closing as REMIND. Reopen if you still get it.
Comment 3 Denis Roy CLA 2009-08-30 02:05:08 EDT
As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.