Community
Participate
Working Groups
Build ID: I20070601-1539 Steps To Reproduce: I'm having a strange problem in a large project of mine. It manifests in code that looks like the code below, where a static class is defined in either an abstract class or an interface. Sometimes, when I sync my client, and get the system to refresh, it will start getting a few errors that reads (adjusted for the example below): Duplicate nested type MyException Now, if I come to the Foo class and "touch" it (say add and remove a space), save and re-compile, the error(s) in that file is(are) gone. This happens consistently in several clients on several computers, but, interestingly, always happens when I use a particular set of eclipse inclusion globs. With a different set of inclusions, those errors never happen (even if the inclusions include some of the files with "problematic pattern"). I don't know if this is relevant at all, but 3 out of the 4 errors are where MyException extends some exception. The 4th is in a file where there is another error already from a class that extends some exception. 3 of the classes are abstract classes, and 1 is an interface. public abstract class Foo { public static class MyException extends Exception {} } public class Bar extends Foo {}
Any chance we can get a hold of the entire project to find the problem ? Or at least enough of the classes to reproduce it ?
Sorry, closed source. And very large. I don't know exactly what's the minimum amount of code to reproduce, and, as I said, reproducing itself is affected by refreshes/recompiling and inclusion globs... I know it sucks to get a report that you can't reproduce, and I avoid filing those... but this is consistently coming back, so I know it's not totally non-derterministic.
I accept that your seeing a problem, but we'll need a reproduceable case. Please try to narrow it down to a few class definitions (no methods are needed). Also can you count how many source files are in your project.
There are tens of thousands of files in my "src" directory, but about 70% of these are not considered "sources" by Eclipse, for we use an elaborate set of inclusion globs. And as I mentioned, changing the globs causes the errors to go away, even if they still include files that had that error in them before.
Does every full/clean build produce the same 4 duplicate errors? Please paste in the type declarations from each duplicate file.
We'll need more info to track this down. If any other users encounter this problem, PLEASE attach a reproduceable testcase. thx
Is there any way I can trace/debug something in my env? Is there any way to have the message list where the other one of these "duplicates" is defined?
The way we've been able to reproduce it is a little more convoluted. You need to have a JAR file that references the inner class static class/enum, but doesn't contain that class. We have an ANTLR built jar file that does this. A full rebuild will cause the error to happen, probably because it's referenced from the main project and the jar file as well. It doesn't matter where I reference these inner classes/enum from, as long as they are inner, and referenced from that Jar file I just did this with the sample below and it caused it to happen. Use the sample code below, and compile a file like this package test; public class Other { public void test() throws MyException { } } Into a jar file (test.jar), making sure that Foo and Bar aren't included. Then create a project including Foo, Bar, and the jar file. I was able to reproduce it.
Sorry Steven your example is not very clear. What is the source for Foo and Bar ? And since the jar file is built using a different builder/compiler, I fail to see how it could impact the JavaBuilder as it compiles your source files... but I'm more than willing to walk thru any example you can provide. Zorzella, if you could describe who/where the "duplicate nested types" are defined, it would help us narrow down where we could add tracing. Then we'll definitely give you a jdt_core jar replacement.
(In reply to comment #8) I am also seeing this problem now, and it reminds me of a similar problem I have seen in the past, again related to the use of a class that the source in the eclipse project defines, but which is used from a jar file. I know this might sound a little unusual, but if you are working on a large enough code base (we are) and just want to work on a small corner of it, making jars dependent on classes in the source code happens a lot. Anyway - the problem has surfaced a couple of times in the last year or so of using 3.2, but is clearly much more of an issue in 3.3 (since I upgraded, on the same codebase, I now see 13 of these compile errors linked to duplicate nested types). When I saw the problem in 3.2 I tried to create a small example to demonstrate but was unable to do so (and I can't send you the sources I am working on unfortunately :-) ), but perhaps it will be easier to re-create now since it seems to be more common. Thanks > The way we've been able to reproduce it is a little more convoluted. You need > to have a JAR file that references the inner class static class/enum, but > doesn't contain that class. We have an ANTLR built jar file that does this. A > full rebuild will cause the error to happen, probably because it's referenced > from the main project and the jar file as well. It doesn't matter where I > reference these inner classes/enum from, as long as they are inner, and > referenced from that Jar file > > I just did this with the sample below and it caused it to happen. Use the > sample code below, and compile a file like this > > package test; > > public class Other { > public void test() throws MyException { > } > } > > Into a jar file (test.jar), making sure that Foo and Bar aren't included. Then > create a project including Foo, Bar, and the jar file. I was able to reproduce > it. >
Created attachment 76591 [details] testcase I've hit this bug as well, trying to build IcedTea (a fully opensource derivate of Sun's OpenJDK) with ecj 3.3. Attached is a testcase reproducing the bug - I've simplified it as much as possible. They key seems to be the use of the inner class/enum in the NoSource class, and the order of the imports in the Test class.
Francis - I think that's a different problem since its outside the IDE. Is everyone else building their project & seeing this problem inside the IDE ?
(In reply to comment #12) > Francis - I think that's a different problem since its outside the IDE. > > Is everyone else building their project & seeing this problem inside the IDE ? > That's the exact same problem I've been seeing.
Sorry Steve - are you seeing the problem inside the IDE or outside using ecj ?
I see it through the IDE (as do the other commenters on the bug). I run ecj on src2, put that in a jar, include the jar in an IDE with the src1 package. If you put them both in the IDE it doesn't work, because they have a circular dependency. If you put Foo.java in both projects it figured it out. If it's reading it from a .class or .jar file it dies.
There is still a circular dependency between the jar & the remaining source files. The types in the jar need to see the .class files for the types in the source folder AND the types in the source folder need to see jar. BTW I still have not reproduced the 'Duplicate nested type error' inside the IDE using the jar file. I have produced another error that says it cannot find the nested type, which is referenced from the jar file.
OK - I take it back. I have now reproduced the problem inside the IDE.
Released a fix to ClassScope into HEAD. Can each of you please try a nightly build (dated later than Aug 22/07) to see if it fixes your problem in the IDE & let us know. I think this will do the trick and we'll backport it to 3.3.1 if that's the case.
Thanks for the quick turnaround! The nightly build works for me.
Added IncrementalBuildTests testMemberTypeCollisionWithBinary2() Fix released into HEAD for 3.4M2
(In reply to comment #20) > Added IncrementalBuildTests testMemberTypeCollisionWithBinary2() > > Fix released into HEAD for 3.4M2 > Solved all of our problems as well. Thanks! Will it be backported to 3.3.1?
Yep - just needed to finish running some tests. Released into 3.3.1 stream
+1 for 3.3.1
The test case is org.eclipse.jdt.core.tests.builder.IncrementalTests (#testMemberTypeCollisionWithBinary2) indeed - wrong class name. Verified for 3.3.1 using build M20070831-2000.
Verified for 3.4M2 using I20070917-0010.
