Community
Participate
Working Groups
HEAD A raw field access is not flagged as an unsafe type operation. Javac only flags all raw write-accesses to field t, i.e. the setter call and the direct field assignment (see below). Eclipse flags both getter and setter calls, but none of the field access / assignment. The field assignment must be flagged, since it is unsafe. However, I cannot see a type safety problem for the getter call and for the field access. IMO, the last two should be flagged with a new style warning ("Should not use raw type") at every raw reference to type 'Cell' in code (the variable type and the constructor call), but not with a type safety problem on innocent method calls (introduced with bug 85815 ?). class Cell<T> { T t; public void setT(T t) { this.t= t; } public T getT() { return t; } } class CellTest { public static void main(String[] args) { Cell c= new Cell(); c.setT(Boolean.FALSE); //javac: warning: [unchecked] unchecked // call to setT(T) as a member of the raw type p.Cell c.t= Boolean.TRUE; // javac: warning: [unchecked] unchecked call // to setT(T) as a member of the raw type p.Cell boolean b1= (Boolean) c.getT(); boolean b2= (Boolean) c.t; } }
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
