Bug 159987

Summary: [clean up] cleanup changes logic by removing cast that it shouldn't
Product: [Eclipse Project] JDT Reporter: Dominik Stadler <dominik.stadler>
Component: CoreAssignee: Philipe Mulet <philippe_mulet>
Status: RESOLVED DUPLICATE QA Contact:
Severity: major    
Priority: P3 CC: benno.baumgartner
Version: 3.2   
Target Milestone: 3.3 M3   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Dominik Stadler CLA 2006-10-06 06:06:31 EDT
I have a piece of code that stopped working after I applied the cleanup-functionality. 

The following testcase shows the problem, in the original code, the (long)-cast causes the Object-array to be filled with an object of type "Integer" (through auto-boxing). 

The cleanup removes the "(long)", which means that the object in the object-array will become an "Integer" instead, which definitely affects behaviour.


    public void testEclipseCleanupError()
    {
        //////////////////////////////////////////////////
        // before cleanup
        //////////////////////////////////////////////////
        final Object[] value1 = new Object[]{(long)1234567};
        
        Long l1 = (long)1234567;
        assertEquals(l1, value1[0]);
        

        //////////////////////////////////////////////////
        // after cleanup
        //////////////////////////////////////////////////
        final Object[] value2 = new Object[]{1234567};
        
        Long l2 = (long)1234567;

        // this fails!
        ///assertEquals(l2, value2[0]);

        assertEquals(new Long(1234567), l2);

        // the value is autoboxed to Integer! 
        assertEquals(new Integer(1234567), value2[0]);
    }
Comment 1 Olivier Thomann CLA 2006-10-06 08:44:02 EDT
Move to JDT/UI
Comment 2 Philipe Mulet CLA 2006-10-07 04:49:09 EDT
Could be related to a wrong diagnosis for unnecessary cast (haven't investigated)
Comment 3 Benno Baumgartner CLA 2006-10-09 05:47:45 EDT
This is correct Philippe, the clean up just removes all casts which are reported as unnecessary by the compiler (JavaCore.COMPILER_PB_UNNECESSARY_TYPE_CHECK):

I20061003-0800

public class Test {
	public static void main(String[] s) {
		Object[] o= new Object[] {(long)1234567};
		if (o[0].equals((long)1234567)) {
			System.out.println("!Bumm");	
		} else {
			System.out.println("Bumm");
		}
	}
}

The first cast is repored as unnecessary, but removing it does change the semantic of the code silently. Raising to major since this semantic change is hard to detect for the user and the 'remove unnecessary casts' clean up is enabled by default.
Comment 4 Philipe Mulet CLA 2006-10-25 07:34:35 EDT
Interestingly, we only issue offending unnecessary cast warning for array initializers.

public class X {
	public static void main(String[] s) {
		Object o1 = (long) 1234567; // no unnecessary cast warning
		Object[] os1 = new Object[] { (long) 1234567 }; // should not warn
	}
}
Comment 5 Philipe Mulet CLA 2006-10-25 07:58:58 EDT
More scenarii, only array initializers are complaining.

public class X {
	public static void main(String[] s) {
		Object o1 = (long) 1234567;
		Object[] os1 = new Object[] { (long) 1234567 };
		Object[] os2 = { (long) 1234567 };
		foo((long) 1234567);
	}
	static void foo(Object o) {
	}
}
Comment 6 Philipe Mulet CLA 2006-10-26 09:56:03 EDT
Added AutoboxingTest#test128.

Problem in fact comes from issue described on bug 162400.
Checked that fix for bug 162400 actually addresses this issue as well; since when expected type is properly set for array initializer expressions, the unnecessary cast diagnosis behaves properly from now on.

Marking as dup of bug 162400, same problem, just different symptoms.

*** This bug has been marked as a duplicate of 162400 ***