Community
Participate
Working Groups
Follow-up to bug 468853: The new BuilderTests#testBug468853() fails with a SourceTypeCollisionException when I use: AbstractImageBuilder.MAX_AT_ONCE = 1; // not "= 2" org.eclipse.jdt.internal.compiler.lookup.SourceTypeCollisionException at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.buildTypeBindings(CompilationUnitScope.java:137) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.buildTypeBindings(LookupEnvironment.java:199) at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:814) at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:930) at org.eclipse.jdt.internal.compiler.Compiler.processCompiledUnits(Compiler.java:603) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:458) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:367) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:179) ... The problem is that Compiler#compile(ICompilationUnit[]) calls processCompiledUnits(0) outside of a try-catch SourceTypeCollisionException block, and hence the internal exception escapes from the compiler. I think this problem was introduced by the fix for bug 437414, which added the unprotected call to processAnnotations(). I can't really judge how big this problem is in practice.
No progress yet and unlikely to get time during 4.6. Moving out.
I get this exception with Eclipse Oxygen when importing the Gerrit project: $ git clone --recursive https://gerrit.googlesource.com/gerrit $ cd gerrit && tools/eclipse/project.py # Import gerrit as existing project
interestingly i don't get it with gerrit (building that too :)), but with an internal closed source project, which uses the hibernate-jpamodelgen. It's pretty much a blocker for me. any way around it?
We're using ECJ in a semi-headless environment (Eclipse Workbench is running with a headless rendering engine). In this scenario I DON'T get the exception when run from the command line. I do ALWAYS get the Exception when I do the very same by starting the VM running ECJ from another Eclipse (regardless of debug/not-debug).
Setting -DmaxCompiledUnitsAtOnce=1000000 seems to help for our scenario.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Starting with Eclipse 2023-09, using annotation processor from hibernate-jpamodelgen-5.6.15.Final.jar, we face this (or at least related) problem again: Classes that were successfully generated by the annotation processor, "cannot be resolved" when they are used in some subequent Java code. Manually performing some no-op change (add blank) on that Java code to retrigger it's compilation makes the "cannot be resolved" error go away. Reducing -DmaxCompiledUnitsAtOnce=1000000 to 1000 or even 1 brings back the org.eclipse.jdt.internal.compiler.lookup.SourceTypeCollisionException again. Thoughts? Eventually, I may be able to debug this into more detail, but any additional information or hint upfront would be highly appreciated.
(In reply to Michael Haubenwallner from comment #8) > Starting with Eclipse 2023-09, using annotation processor from > hibernate-jpamodelgen-5.6.15.Final.jar, we face this (or at least related) > problem again: > Classes that were successfully generated by the annotation processor, > "cannot be resolved" when they are used in some subequent Java code. > Manually performing some no-op change (add blank) on that Java code to > retrigger it's compilation makes the "cannot be resolved" error go away. This is handled in https://github.com/eclipse-jdt/eclipse.jdt.core/issues/1654
