Community
Participate
Working Groups
Created attachment 222275 [details] sample project Eclipse reports a compile error but it should be a false-report. I don't get the meaning of this compile error. See the associated projects. In test2 there are two classes. The first class (UserByCustomerIndexImpl) gets the compile error "the interface NonUniqueIndex cannot be implemented more than once[...]" The second class (UserByCustomerIndexImpl2) works. The difference between both is the fact that the second template parameter is a nested class in UserByCustomerIndexImpl and a non-nested class in UserByCustomerIndex2. Expected bahaviour: Eclipse should not complain. I did not find any hint in the specification that is compile error is a wanted behaviour. Actually I do nothing forbidden. The interface is implemented twice but both should result in the same template parameters. I do not do "implements IFace<Foo>, IFace<Bar>" or similar things. Eclipse Java Development Tools 3.8.1.v20120814-104540-8-8nFqpFNOfwKDRVz-tXOcL5d_83 org.eclipse.jdt.feature.group Eclipse.org
jdk (1.6.20, 1.7.1, 1.7.6) compiles both classes without error on command line. Maven seems to run into this problem too. Maybe it was a problem in jdk 1.5? However setting compiler compliance level to 1.5, 1.6 or 1.7 does not solve the issue.
After trying various versions of JDT / ecj including Juno SR1 I cannot reproduce, neither in the IDE nor on the command line. Does Eclipse *always* report this error for you? Different compiler settings? Clean vs. incremental build, ect?
Yes, it reproduces it always. On clean, automatic build and manual build.
Maybe if you drive me through I will be able to debug jdt. The error itself, where is it set (Class/Line)?
(In reply to comment #4) > Maybe if you drive me through I will be able to debug jdt. The error itself, > where is it set (Class/Line)? Thanks for the offer. You can plant a breakpoint at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.superinterfacesCollide(TypeBinding, ASTNode, TypeBinding, TypeBinding) and work backwards.
ok, I think I got the problem. I do not know how this happened but I got a version of jdt in my repository named: org.eclipse.jdt.core_3.8.2.v_OTDT_r211_201209011847.jar It is seen here for example: http://www.mirrorservice.org/sites/download.eclipse.org/eclipseMirror/objectteams/updates/ot2.1/plugins/ http://www.eclipse.org/objectteams/ The line numbers don't match. Comparing the source file with the current jdt sources shows up many changes. It seems that this "otdt patch" is out dated. Or maybe this bug exists because they broke the most recent version of jdt with their patch. Maybe you should forward this bug to them? However for me it is ok since I simply converted the inner class to a new class file in my projects.
(In reply to comment #6) > ok, I think I got the problem. > > I do not know how this happened but I got a version of jdt in my repository > named: > org.eclipse.jdt.core_3.8.2.v_OTDT_r211_201209011847.jar > It is seen here for example: > http://www.mirrorservice.org/sites/download.eclipse.org/eclipseMirror/ > objectteams/updates/ot2.1/plugins/ > http://www.eclipse.org/objectteams/ OK, thanks for letting us know! That explains why I couldn't reproduce early, and using OTDT I can now see the problem. As for how this happened: most likely you installed at some point the following feature: Object Teams Patch for JDT/Core with this description: This feature is NOT a regular update of the JDT, but REPLACES the org.eclipse.jdt.core plugin by the corresponding version for Object Teams. This change makes the JDT Core capable to handle OT/J code. It's a known limitation in p2 that it suggests this feature during *check for updates* in certain (rare) scenarios. > The line numbers don't match. Comparing the source file with the current jdt > sources shows up many changes. It seems that this "otdt patch" is out dated. Not outdated, it's the exact version of Juno SR1, containing all the bits of JDT of that version, plus more. > Or maybe this bug exists because they broke the most recent version of jdt > with their patch. > > Maybe you should forward this bug to them? Doing so, and assigning to myself as I'm actually to blame for the bug in Object Teams :-/ > However for me it is ok since I simply converted the inner class to a new > class file in my projects. You could also try to uninstall the above feature to go back to a pristine JDT/Core.
Test & fix released for 2.2 M3 (Object Teams) via commit 26763a32a6b9015482e767ab5d39c8e16682445e The culprit was one too many levels of wrapping a type binding (role types, unresolved types, parameterized types), so we ended up with with different instances representing the exact same type, which then led to the bogus error about different type arguments.
Comment on attachment 222275 [details] sample project Setting the IP flag on the attachment because the example project is used as a test case. Thanks.
Released for 2.1.2 RC1 via commit d3f70883eab84c03a55e8526eb4cdb2b819751ea.
Verified for OTDT 2.2 using build 201306071500
