JDK-6228028 : Issue a lint warning when a raw class implements a generic
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: linux
  • CPU: x86
  • Submitted: 2005-02-11
  • Updated: 2010-08-20
  • Resolved: 2010-08-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Relates :  
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
If you have an interface that has methods with parameters of generic type, javac lets you impelement them with raw types.compile them without any warnings. See the supplied source code for an example. If the implemented method does not try to perform any type-checked operations on parameter, then the developer gets no warning

This technically fulfills the contract for "unchecked" warnings, because no checked operations are called on the list parameter and thus it is statically type safe (hence, I have not reported it as a bug). However, I believe it is counter-intuitive. I would like to see the test case provided generate an unchecked warning, or at the very least some other new warning type. For the sake of backward compatibility, it obviously cannot be treated as an error.

JUSTIFICATION :
When migrating code it is unfeasible to check each class individually to ensure that you have implemented generics properly in each one. The developer must rely on the compiler to do it.

The intuitive understanding of "unchecked" warnings is that code that compiles without unchecked warnings has been fully genericised, and a lack of a warning in this case intially came as a surprise to me. I discovered that one of my packages had not been fully genericised even though it compiled without unchecked warnings - I updated the method signature of an interface, without updating all of the method signatures of the implementing classes.

A combination of this feature and a solution for another RFE that I recently reported (INTERNAL ID: 393624) will allow developers to find and remove a lot more pre-generic lint from their code, and help avoid potential nasty surprises down the track.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Compiler to issue an "unchecked" warning for the line where Unsafe.addElement(List) is declared (see supplied test case code).
ACTUAL -
Code successfully compiles without warnings.

---------- BEGIN SOURCE ----------
import java.util.*;

interface Safe
{
  public void addElement(List<String> list);
}


class Unsafe implements Safe
{
  public void addElement(List list)
  {
    // Compiles without warning. Would be nice to know that we could make use of the
    // type-safety of the list parameter when invoking get().
  }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Find all implementing classes of the genericised interface and check all of their methods that have parameters with generic types.
###@###.### 2005-2-11 00:43:42 GMT

Comments
EVALUATION To prove the point: import java.util.*; class Safe { public void addElement(List<String> list) { String s = list.get(0); }; } class Unsafe extends Safe { @Override public void addElement(List list) { super.addElement(list); //warning here!! } public static void main(String[] args) { List<Integer> li = new ArrayList<>(); li.add(10); new Unsafe().addElement(li); } }
20-08-2010

EVALUATION The example provided isn't unsafe. As List is a supertype of List<String>, addElement(List) is a subtype of addElement(List<String>) which makes the override type safe. However, we should consider adding lint warnings for use of raw types to aid developers rid their programs of raw types. ###@###.### 2005-2-12 19:09:21 GMT
12-02-2005