Bug 69542

Summary:	[1.5] ByteCode differs from javac ByteCode in behaviour
Product:	[Eclipse Project] JDT	Reporter:	Karsten Becker <java>
Component:	Core	Assignee:	Philipe Mulet <philippe_mulet>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	3.0
Target Milestone:	3.1 M1
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Karsten Becker

2004-07-07 18:15:36 EDT

Hi,
The following Code:
	static class Container<T>{
	    private T val;
	    public T getVal() {
	        return val;
	    }
	    public void setVal(T val) {
	        this.val = val;
	    }
	}
	public static void badMethod(Container<?> param){
	    Container x=param;
	    x.setVal("BAD");
	}
	public static void main(String[] args) {
	    Container<Integer> cont=new Container<Integer>();
	    cont.setVal(new Integer(0));
	    badMethod(cont);
	    System.out.println(cont.getVal()); //ClassCastException
}
leads to:
Exception in thread "main" java.lang.ClassCastException: java.lang.String
	at SpecialTest.main(SpecialTest.java:57)
when executed within Eclipse.
But JVM just prints: BAD

Comment 1 Philipe Mulet

2004-07-08 11:54:07 EDT

Looks like javac doesn't perform the checkcast, and thus doesn't notice the 
problem.
If replacing line:
	    System.out.println(cont.getVal()); //ClassCastException
with:
	    Integer someVal = cont.getVal();

Then it will generate the checkcast, and thus raise the ClassCastException.

Comment 2 Philipe Mulet

2004-07-08 12:09:15 EDT

We should be more permissive in generic cast emission. If the type expectation 
is lower, we should not check as much.
e.g.
Integer val1 = cont.getVal();  // checkcast Integer
Number val2 = cont.getVal();  // checkcast Number
Object val3 = cont.getVal();  // no checkcast

Comment 3 Philipe Mulet

2004-07-09 17:29:47 EDT

Tuned generic cast to be less strict so as to only match expectation.
Added regression tests GenericTypeTest#test232-239.

Fixed