Community
Participate
Working Groups
I20071029-0010 Fup on bug 168230. Checked that we still bark at the following at 5.0 and 6.0 compliance levels, whereas javac does not: public class X extends Y { public String foobar(String one, String two) { return this.<String>foobar(one, two); } } class Y { public <T> String foobar(String one, String two) { return null; } } Modified GenericTypeTest#1203 accordingly.
*** Bug 150655 has been marked as a duplicate of this bug. ***
Strange... I was thinking it would pick the super method due to presence of generic super method, but no. When running the following, it prints "X#foobar" There seems to be some tolerance for the fact where a super method is generic. public class X extends Y { public static void main(String[] args) { new X().<String> foobar("1","2"); } public void foobar(String one, String two) { System.out.println("X#foobar"); } } class Y { public <T> void foobar(String one, String two) { System.out.println("Y#foobar"); } }
Indeed, the presence of a super generic method is sufficient in java5 or java6 mode to allow for unused type arguments: i.e. the following is rejected: public class X extends Y { public static void main(String[] args) { new X().<String> foobar("1","2"); } public void foobar(String one, String two) { System.out.println("X#foobar"); } } class Y { public void foobar(String one, String two) { System.out.println("Y#foobar"); } } (only tolerated in java7)
Kent - maybe now is the time to introduce a link from a method to its super method.
Actually the super method is not needed at all. With this case: class X { void foobar(String one, String two) {} void test(X x) { x.<String>foobar("1", "2"); } } Only javac 7 compiles without an error or warning. 1.5 & 6 complain. Philippe - I think we should just remove our error to be compatible with 7
Created attachment 129870 [details] Proposed patch and testcase
Fix and test released for 3.5M7
Verified for 3.5M7 using build I20090426-2000
