Summary: | [1.5][compiler] Raw field access is not flagged as unsafe type operation | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> |
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | dirk_baeumer, martinae |
Version: | 3.1 | ||
Target Milestone: | 3.1 M6 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Markus Keller
2005-03-01 07:53:33 EST
The getter method is not completely innocent as it will answer a value which may not match expectation. It is consistent with situations where arguments are altered due to raw receiver types. As for flagging the use of a field defined on a raw type, I will investigate further. Providing an extra diagnosis for raw type references is something which could also be added. Only raw field assignments are to be diagnosed. Will queue this enhancement request for later. We are consistent with javac. No, we are not consistent with javac. Javac only gives an unchecked warning when the same call could be invalid if the target is parameterized rather than raw. JLS3 5.1.9 specifies that an 'unchecked' warning is issued for every unchecked conversion from a raw type to a parameterized type. Cell<Boolean> bc= new Cell<Boolean>(); Cell c= bc; c.setT("Hello"); //javac: unchecked c.t= "World"; //javac: unchecked // After this point, a call to bc.getT() may throw a ClassCastException! // Therefore, the two 'unchecked' warnings above are required. bc.setT("Hello"); //both: error bc.t= "World"; //both: error On the other hand, there's never a type safety issue with a getter invocation / field access. The only issue there is that the return type of the raw method call may not be as specific as one would like. This may require an additional cast (which is and has always been unchecked). Boolean b1= (Boolean) c.getT(); Boolean b2= (Boolean) c.t; Boolean b3= (Boolean) bc.getT(); //eclipse: unnecessary cast Boolean b4= (Boolean) bc.t; //eclipse: unnecessary cast IMO, the decision of bug 85815 to merge these two kinds of problems (setter: unchecked / getter: not as specific as it could be) into one warning was wrong. Actually you are right. I was mistaken in seeing us reporting the raw field assignment. As for the debate on getter/setter situation, this is another issue, and you should discuss in bug 85815. Adding an extra option to make our control stricter is always possible, though likely hard to present in any UI, but still doable. reopen Added GenericTypeTest#test559. Fixed Verified in I20050330-0500 |