Summary: | [compiler][1.5] unclear type bound resolution | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Tom Hofmann <eclipse> |
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
Status: | RESOLVED INVALID | QA Contact: | |
Severity: | minor | ||
Priority: | P3 | CC: | markus.kell.r |
Version: | 3.1 | ||
Target Milestone: | 3.1 M5 | ||
Hardware: | PC | ||
OS: | All | ||
Whiteboard: |
Description
Tom Hofmann
2005-01-05 10:08:28 EST
What exactly do you mean by "Inlining the call to B.getTwo produces an error..." ? [I jump in because Tom is away and we looked at this together.] If you inline the call to "b.getTwo()" (either manually, or with Refactor > Inline), the call becomes "b.getOne()" (already done in "n1= b.getOne();" in the line above). "... produces an error ... " means that the compiler marks an error here: Number n1= b.getOne(); ^^ Type mismatch: cannot convert from Object to Number We can't see why the statement "Number n1= b.getOne();" is marked as an error. The upper bound of the return type of B#getOne() is Number. Therefore, the object returned from B#getOne() must always be a Number or a subtype of Number, and the statement "Number n1= b.getOne();" should be valid. The return type of #getTwo() is Number, which definitely matches expectation for n2. For n1, the invocation of b.getOne() is performed on raw type B. The superclass of raw type B is raw type A, which defines a method #getOne() of type: erasure of <E> --> Object (since it carries no bound). Thus the invocation of #getOne() returns an Object, which isn't compatible with Number. |