Community
Participate
Working Groups
Every time java build process stops with a SourceTypeCollisionException. I checked this in all eclipse versions since Luna. So we are unable to switch to a newer release. A colleague opened a bug report in 2015: https://bugs.eclipse.org/bugs/show_bug.cgi?id=471217 It still appears with a changed Stacktrace: eclipse.buildId=4.7.1.M20171009-0410 java.version=1.8.0_131 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE Framework arguments: -product org.eclipse.epp.package.jee.product Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product org.eclipse.core.resources Error Fri Nov 10 12:57:10 CET 2017 Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". org.eclipse.jdt.internal.compiler.lookup.SourceTypeCollisionException at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.buildTypeBindings(CompilationUnitScope.java:167) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.buildTypeBindings(LookupEnvironment.java:457) at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:838) at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:954) at org.eclipse.jdt.internal.compiler.Compiler.processCompiledUnits(Compiler.java:626) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:468) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:419) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:372) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:187) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:332) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:61) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:256) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:175) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:142) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:232) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
(In reply to Carsten Trautmann from comment #0) > A colleague opened a bug report in 2015: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=471217 If it's the same issue, then that one will do just fine. While it would be possible to understand from stack that there is one spot where we don't handle SourceTypeCollisionException, I don't have an explanation that would cause this. I would like to have a test case where a type was found during a later stage but not during the compilation. In other words, we never expected this to happen during processCompiledUnits(). I am asking again (the question on 471217 went unanswered) - would you be able to share the project where this happens or the steps to reproduce this?
*** This bug has been marked as a duplicate of bug 471217 ***
Sorry, I can't share our code because I'm not the owner of the code. What I see: there is one JAR configured in the Annotation Processing Factory Path, which is causing the error. If I disable it, the compilation is successful, but some classes are not generated.
(In reply to Carsten Trautmann from comment #3) > Sorry, I can't share our code because I'm not the owner of the code. What I > see: there is one JAR configured in the Annotation Processing Factory Path, > which is causing the error. If I disable it, the compilation is successful, > but some classes are not generated. Are you in a position a try out a patch if I can provide?
(In reply to Jay Arthanareeswaran from comment #4) > Are you in a position a try out a patch if I can provide? I'm not familiar with the eclipse patch process. So I don't know how you provide a patch. But I'm able to change everything within my eclipse directory.
(In reply to Carsten Trautmann from comment #5) > I'm not familiar with the eclipse patch process. So I don't know how you > provide a patch. But I'm able to change everything within my eclipse > directory. That should be fine. I will provide the patch as a Jar. Please let me know the version of jdt.core plugin you have in your eclipse installation. You will find it under <eclipse_ins>/plugins directory.
(In reply to Jay Arthanareeswaran from comment #6) > That should be fine. I will provide the patch as a Jar. Please let me know > the version of jdt.core plugin you have in your eclipse installation. You > will find it under <eclipse_ins>/plugins directory. Found this one: org.eclipse.jdt.core_3.13.50.v20171007-0855.jar
Created attachment 271448 [details] Proposed fix as jar Please update your Eclipse with this JAR after taking a back-up of the existing and try the compiler again.
(In reply to Jay Arthanareeswaran from comment #8) > Please update your Eclipse with this JAR after taking a back-up of the > existing and try the compiler again. Checked this bugfix out. Good news: The SourceTypeCollisionException is gone. Bad news: Now a NullPointer occurs which is bundled with the same configured JAR. So it might be a consequence of the bugfix. java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.Compiler.backupAptProblems(Compiler.java:508) at org.eclipse.jdt.internal.compiler.Compiler.processCompiledUnits(Compiler.java:629) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:468) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:419) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:372) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:187) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:332) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:61) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:256) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:175) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:263) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:403) at org.eclipse.core.internal.resources.Project$1.run(Project.java:566) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240) at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:544) at org.eclipse.core.internal.resources.Project.build(Project.java:112) at org.eclipse.jdt.internal.ui.util.CoreUtility$BuildJob.run(CoreUtility.java:159) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
(In reply to Carsten Trautmann from comment #9) > Bad news: > Now a NullPointer occurs which is bundled with the same configured JAR. So > it might be a consequence of the bugfix. That's not surprising as the Compilation units have already been processed. We can't do much but add a null check there. I will do some more testing and release the change. The annotation processor you mentioned - is this something that can be shared?
(In reply to Jay Arthanareeswaran from comment #10) > The annotation processor you mentioned - is this something that can be > shared? Sorry, the annotation processors used in our project are bundled with PTC Windchill / PDMLink und are under its license.
When will the bugfix come?