Summary: | [1.5][compiler] Missing error when implementing a method with a mix of parameterized and raw generics | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Michael Lupp <m.lupp> | ||||||||||
Component: | Core | Assignee: | Maxime Daniel <maxime_daniel> | ||||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||||
Severity: | major | ||||||||||||
Priority: | P3 | ||||||||||||
Version: | 3.2.2 | ||||||||||||
Target Milestone: | 3.3 M6 | ||||||||||||
Hardware: | PC | ||||||||||||
OS: | Windows XP | ||||||||||||
Whiteboard: | |||||||||||||
Attachments: |
|
Description
Michael Lupp
2007-03-01 03:50:34 EST
Reproduced with I20070222-0951 (no message) and javac 1.5.0_11, 6_01_b03, 7_b06 (error). I believe this is related to bug 166355, that I would tackle first. Released (inactive) test case MethodVerifyTest#122 in HEAD. With this example: interface I { void a(List<String> i, List<String> j); void b(List<String> i, List<String> j); void c(List i, List<String> j); } class X implements I { public void a(List<String> i, List j) {} // doesn't implement I.a public void b(List i, List j) {} public void c(List i, List j) {} } We need to know whether an 'overriding' method has any parameterized type parameters. If it has a single parameterized type parameter, then it cannot have raw types matching inherited parameterized types. (need to ask the method isParameterized() ?) It cannot be a case of compatibility, since the 'overriding' method has been partially changed to match the 'new' inherited method with its new parameterized type arguments. Created attachment 60385 [details]
Proposed patch
Thanks for the patch Kent. I released a tuned error message for MethodVerifyTest#122. It also shows that this bug is not related to 166355. Reading your patch, I would suggest that the name of the boolean variable that controls the search for parameterized types in parameters loose its reference to a conversion. What we want to say is that if any of the method parameters has a raw type, then none must have a parameterized type, which is kind of a 'static' property - whatever dynamics may bring it there. Moreover, the variable is used to avoid double-check, knowing that a failing check returns (as false). I would then propose: methodOneAllArgTypesRawChecked, using the opposite logic (starting with false). Please let me know what you think. Created attachment 60482 [details]
Proposed fix
Implements the suggestion above.
Created attachment 60483 [details]
Alternative fix
In this one, I have explicitly separated the situations so as to minimize tests. It's a bit radical in design, but I thought the option would be worth discussing it.
Created attachment 60486 [details]
2 loops
I like the second patch but would tweak it just a bit to keep the test the same.
How about this ?
Looks better (easier to understand). Released for 3.3 M6. Verified for 3.3 M6 using build I20070323-1616. |