Community
Participate
Working Groups
We just noticed during a tutorial with our students that the following code does no longer compile with Eclipse 3.6 but compiles fine in previous versions of Eclipse: public class BugGenerics { public static int[] doIt(Collection<int[]> col) { if (!col.isEmpty()) return col.iterator().next(); return new int[0]; } public static int[][] doIt(Collection<int[][]> col) { if (!col.isEmpty()) return col.iterator().next(); return new int[0][0]; } public int[] doIt2(Collection<int[]> col) { if (!col.isEmpty()) return col.iterator().next(); return new int[0]; } public int[][] doIt2(Collection<int[][]> col) { if (!col.isEmpty()) return col.iterator().next(); return new int[0][0]; } } The error reported by ECJ is for instance Description Resource Path Location Type Method doIt(Collection<int[][]>) has the same erasure doIt(Collection<E>) as another method in type BugGenerics BugGenerics.java /BugsEclipse/src/fr/univartois/ili/bugs line 12 Java Problem while the same code compiles just fine with Javac 1.6.0_20 (under Mac OS X) and ECJ M20090826-1100 for instance.
This doesn't compile anymore using javac 1.7. c:\tests_sources>javac BugGenerics.java BugGenerics.java:10: name clash: doIt(Collection<int[][]>) and doIt(Collection<int[]>) have the same erasure public static int[][] doIt(Collection<int[][]> col) { ^ BugGenerics.java:22: name clash: doIt2(Collection<int[][]>) and doIt2(Collection<int[]>) have the same erasure public int[][] doIt2(Collection<int[][]> col) { ^ 2 errors Looks like a duplicate of bug 317719. I guess your tutorial has to be updated :-). *** This bug has been marked as a duplicate of bug 317719 ***
The problem is that we are not in Java 1.7, but in Java 1.6. How can I explain to my colleagues that their code which work fine with OpenJDK or Sun JDK for years, but does not longer work with Eclipse 3.6 is buggy? In 1.6 mode, Eclipse compiler should accept that code.
We had a debate over this and since this was flagged as a bug against javac 1.5, we believed that it is not helpful to "accept" a code that will be rejected in the next version of javac. Note that an update of javac 1.6 could contain the fix as well, but so far backporting fixes is not a common practice for javac implementation. See bug 317719 comment 2.
Thanks for the details, Olivier. I agree that such code is buggy because of the way Java currently implements generics with type erasure. It is not buggy from a design point of view. (It is currently a limitation of the language). However, I would have preferred to see a warning here in 1.6 mode. I guess few people use currently generics in production software, so that is the reason why few people got caught by this change of behavior, but it is really a pain IMHO to have ECJ behaving differently than the other java compilers on that code.
(In reply to comment #4) > I guess few people use currently generics in production software, so that is > the reason why few people got caught by this change of behavior, but it is > really a pain IMHO to have ECJ behaving differently than the other java > compilers on that code. Daniel, just to make it clear. Besides javac, I don't really know any other java compiler :-). javac agrees that this code is boggus (as you said this is a limitation of the language) and they fixed it in JDK7 stream. Now the are not very good as backporting fixes to early streams like 1.6. What would happen if they publish an update of 1.6 that contains the fix (so they would report an error) and we change our code to only report a warning ? We would be inconsistent again. I think you should open a bug report for the addition of a warning in 1.6 mode for this issue so that we can discuss all the pros and cons of such a new setting. Verified for 3.7M3. (internal verification)
junit has been added as a part of the fix for bug 317719
Verified for 3.7.1 RC2 using build M20110824-0800
Verified for 3.8M2 with build I20110912-2126.
