Bug 175987 - [1.5][compiler] Missing error when implementing a method with a mix of parameterized and raw generics
Summary: [1.5][compiler] Missing error when implementing a method with a mix of parame...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2.2   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.3 M6   Edit
Assignee: Maxime Daniel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-01 03:50 EST by Michael Lupp CLA
Modified: 2007-03-26 23:49 EDT (History)
0 users

See Also:


Attachments
Proposed patch (1.78 KB, patch)
2007-03-07 12:25 EST, Kent Johnson CLA
no flags Details | Diff
Proposed fix (2.29 KB, patch)
2007-03-09 10:23 EST, Maxime Daniel CLA
no flags Details | Diff
Alternative fix (2.64 KB, patch)
2007-03-09 10:24 EST, Maxime Daniel CLA
no flags Details | Diff
2 loops (2.72 KB, patch)
2007-03-09 12:06 EST, Kent Johnson CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Lupp CLA 2007-03-01 03:50:34 EST
Build ID: M20070212-1330

Steps To Reproduce:
1. Create an interface with a method with generics:
-----------------------------------
import java.util.List;

public interface IFtest {
	public void doTest(Integer i, List<String> pList, List<String> pList2);

}
-----------------------------------

2. Create a class that implements that interface but that just partly uses generics:
-----------------------------------
import java.util.List;

public class Impl implements IFtest {

	public void doTest(Integer i, List<String> iList, List iList2) {
	}

}
-----------------------------------

3. If this is compiled within eclipse you don't get an error, but if this is compiled with javac outside of eclipse  you get this error:
-----------
Impl.java:3: Impl is not abstract and does not override abstract method doTest(j
ava.lang.Integer,java.util.List<java.lang.String>,java.util.List<java.lang.Strin
g>) in IFtest
public class Impl implements IFtest {
       ^
Note: Impl.java uses unchecked or unsafe operations.
------------

BTW: the eclipse editor shows correctly that Impl.doTest doesn't implements an interface method (the triangle on the left side doesn't appear).
Comment 1 Maxime Daniel CLA 2007-03-02 06:52:54 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. 
Comment 2 Kent Johnson CLA 2007-03-06 16:36:53 EST
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.
Comment 3 Kent Johnson CLA 2007-03-07 12:25:26 EST
Created attachment 60385 [details]
Proposed patch
Comment 4 Maxime Daniel CLA 2007-03-09 05:28:35 EST
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.
Comment 5 Maxime Daniel CLA 2007-03-09 10:23:12 EST
Created attachment 60482 [details]
Proposed fix

Implements the suggestion above.
Comment 6 Maxime Daniel CLA 2007-03-09 10:24:58 EST
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.
Comment 7 Kent Johnson CLA 2007-03-09 12:06:42 EST
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 ?
Comment 8 Maxime Daniel CLA 2007-03-12 04:24:04 EDT
Looks better (easier to understand).
Released for 3.3 M6.
Comment 9 Maxime Daniel CLA 2007-03-26 23:49:15 EDT
Verified for 3.3 M6 using build I20070323-1616.