Bug 527116 - Java Compile breaks up with SourceTypeCollisionException
Summary: Java Compile breaks up with SourceTypeCollisionException
Status: CLOSED DUPLICATE of bug 471217
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.7.1   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-10 07:42 EST by Carsten Trautmann CLA
Modified: 2018-01-30 09:25 EST (History)
3 users (show)

See Also:


Attachments
Proposed fix as jar (6.17 MB, application/octet-stream)
2017-11-14 01:27 EST, Jay Arthanareeswaran CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Carsten Trautmann CLA 2017-11-10 07:42:19 EST
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)
Comment 1 Jay Arthanareeswaran CLA 2017-11-10 10:05:08 EST
(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?
Comment 2 Jay Arthanareeswaran CLA 2017-11-12 23:41:30 EST

*** This bug has been marked as a duplicate of bug 471217 ***
Comment 3 Carsten Trautmann CLA 2017-11-13 06:37:18 EST
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.
Comment 4 Jay Arthanareeswaran CLA 2017-11-13 06:48:07 EST
(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?
Comment 5 Carsten Trautmann CLA 2017-11-13 07:40:45 EST
(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.
Comment 6 Jay Arthanareeswaran CLA 2017-11-13 07:44:20 EST
(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.
Comment 7 Carsten Trautmann CLA 2017-11-13 07:56:52 EST
(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
Comment 8 Jay Arthanareeswaran CLA 2017-11-14 01:27:44 EST
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.
Comment 9 Carsten Trautmann CLA 2017-11-15 05:45:50 EST
(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)
Comment 10 Jay Arthanareeswaran CLA 2017-11-15 06:27:08 EST
(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?
Comment 11 Carsten Trautmann CLA 2017-11-16 02:33:59 EST
(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.
Comment 12 Carsten Trautmann CLA 2018-01-30 09:25:18 EST
When will the bugfix come?