Community
Participate
Working Groups
Build Identifier: That's a strange one. In a certain setup I can see a number of exceptions such as javax.annotation.processing.FilerException: Source file already created: at org.eclipse.jdt.internal.apt.pluggable.core.filer.IdeFilerImpl.createResource(IdeFilerImpl.java:96) at org.example.apt.MyProcessor.process(MyProcessor.java:40) at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:139) at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.round(RoundDispatcher.java:110) at org.eclipse.jdt.internal.compiler.apt.dispatch.BaseAnnotationProcessorManager.processAnnotations(BaseAnnotationProcessorManager.java:159) at org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeAnnotationProcessorManager.processAnnotations(IdeAnnotationProcessorManager.java:134) at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:809) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:428) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:364) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:321) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:328) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:134) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:242) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) being logged. Reproducible: Always Steps to Reproduce: 1. Import the soon-to-be-attached 'org.example' and 'org.example.ui' projects in your workspace (please note that they have a dependency on Xtext 2.1.x, so it should be installed preliminarily - sorry for the inconvenience, but it seems important for reproducing the problem) 2. Launch the runtime ('nested') workbench and create a Worlds Project (File -> New -> Project... -> Other -> Worlds Project). The default settings can be used. 3. Make a clean build of the project created. See the error message (javax.annotation.processing.FilerException: Source file already created) in the 'parent' workbench console. It seems strange to me, but the exception is thrown only if the number of Java files (Worlds and World Views) in the worlds project exceed 2000. The default settings are 2000 and 1, but 1001 and 1000, 1000 and 1001 work just fine (alternative settings can be defined on the second page of the Worlds Project wizard). Of course, Worlds are synthetic example, but they reproduce an issue encountered in real-world.
Created attachment 208824 [details] Code to reproduce the issue
When there are > some number of files in a project, the JDT compiler does them in batches... I suspect the logic around this is not working properly.
(In reply to comment #2) > When there are > some number of files in a project, the JDT compiler does them > in batches... I suspect the logic around this is not working properly. Walter, glad to hear from you! Thanks for the hint! Indeed, AbstractImageBuilder#MAX_AT_ONCE is exactly 2000. Now it explains something. The flag AbstractImageBuilder.compiledAllAtOnce is false in that case, so all the 2001 Java files get to the second iteration of the IncrementalImageBuilder#build(SimpleLookupTable)'s compile loop - see 'if (this.compiledAllAtOnce && ...)' statement in the IncrementalImageBuilder#addAffectedSourceFiles(StringSet...) method. But since AptCompilationParticipant#aboutToBuild is called only at the beginning of the build, the _java6GeneratedFiles set is not cleared after the first iteration of the compile loop, so in the second iteration IdeFilerImpl throws that exception.
Hi, Do you have any plan to fix this issue ? It seems that the issue is reproducible in Eclipse 4.4. I wrote a procedure for reproducing. Please see my GitHub repository. https://github.com/nakamura-to/filer-ex/tree/v0.0.0 Thanks.
I can't make any promise of a fix at this point, will take a look during 4.5 time frame.
Sorry, can't get to it yet. Will still aim Mars. Meanwhile, can I suggest a workaround - bug 386901? Basically, you can set your own batch size using the JVM parameter maxCompiledUnitsAtOnce.
I see the problem. What is happening, in the next around, the original files as well as the generated ones sent for compilation, which is resulting in the problem. The generated files set is also being shared with APT 5. Will have to work it around for this to work. Let me see what we can do here.
Great! I am looking forward to progress on this one. Thx!
(In reply to Vladimir Piskarev from comment #3) > The flag AbstractImageBuilder.compiledAllAtOnce is false in that case, so > all the 2001 Java files get to the second iteration of the > IncrementalImageBuilder#build(SimpleLookupTable)'s compile loop - see 'if > (this.compiledAllAtOnce && ...)' statement in the > IncrementalImageBuilder#addAffectedSourceFiles(StringSet...) method. This line was added way back in 2002 and all I can find in terms of documentation is this comment: // must add previously compiled locations, otherwise we do not find hierarchy related problems Even after removing the "this.compiledAllAtOnce &&" check all tests are passing. But that doesn't mean we are completely safe. I think it's okay to recompile the files again, but we might want to 'not' process them for annotations again. But as of today, the Compiler is happy to forget all the units processed in the previous round. We might want to do something about it. Other alternative I thought is to keep another set (just like _java6GeneratedFiles) for units processed in this round and clear them after every round. But only thing we will achieve is avoid the filer exception and doesn't prevent the files to be annotation processed multiple times. So, the former approach is what I think is appropriate but that looks too complicated at this stage. For now, let me again suggest the workaround of setting the JVM parameter maxCompiledUnitsAtOnce to 0 (zero) so all units compiled in a single round.
If Walter or anyone has a simpler solution in mind, it will be great. Otherwise, moving this out of 4.5. Sorry about it.
My only comment would be that that particular block of code has been an ongoing source of bugs. It was moderately complex (in the sense that it combined several different concerns) before APT was introduced; it then became considerably more complex when we added APT 5 and 6. The right way to handle it would probably be to write a separate class that represents the data structure we're trying to achieve (something like a ChunkedAccumulator) and then refactor the Builder code to use that data structure. That might make the logic more clear, which would then make it easier to maintain.
(In reply to Walter Harley from comment #11) > The right way to handle it ... Thanks for weighing in Walter and thanks for the suggestion. I agree that is the way forward with this one. I shall attempt it after Mars.
No progress yet and unlikely to get time during 4.6. Moving out.
All who use Eclipse with Dagger may catch this issue: https://github.com/google/dagger/issues/442
I also intermittently encounter this bug in Eclipse using GWT Request Factory annotation processor via APT. This is with Eclipse 4.7.0.
Is anyone willing to provide a patch for this one? I am afraid I may not able to spare time fore this any time soon.
This seem to affect not apt only, but all builders running after java builder, like xtext.
Hi. I use AutoValue as annotation processor(and annotations). In the past I hadn't any problems with this bug in my project. It first appeared when I converted to Gradle and now there are warnings for all auto-generated classes. Is it related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=540090 ? If yes, in releases 4.10M3 I20181121-1800 and 4.10RC1 it is not yet fixed (bug 540090 is fixed at 4.10 M3 with build id I20181120-1800 ).
My problem reported in my previous comment 18 is fixed in Eclipse 4.10. Actually, it is fixed release 4.10RC2 where a fix for bug 542090 was provided. I did mention Gradle in my previous comment but it didn't have to do anything with that after all. It had to do with upgrading to Java 11 and the relevant bug 542090.
(In reply to Emmanouil Trypakis from comment #18) > Hi. > I use AutoValue as annotation processor(and annotations). In the past I > hadn't any problems with this bug in my project. It first appeared when I > converted to Gradle and now there are warnings for all auto-generated > classes. > Is it related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=540090 ? If > yes, in releases 4.10M3 I20181121-1800 and 4.10RC1 it is not yet fixed (bug > 540090 is fixed at 4.10 M3 with build id I20181120-1800 ). Sorry, I am confused. Did you mean to say that the bug 542090 was fixed in 4.10 but you still see the problem in 4.10?
(In reply to Jay Arthanareeswaran from comment #20) > (In reply to Emmanouil Trypakis from comment #18) > > Hi. > > I use AutoValue as annotation processor(and annotations). In the past I > > hadn't any problems with this bug in my project. It first appeared when I > > converted to Gradle and now there are warnings for all auto-generated > > classes. > > Is it related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=540090 ? If > > yes, in releases 4.10M3 I20181121-1800 and 4.10RC1 it is not yet fixed (bug > > 540090 is fixed at 4.10 M3 with build id I20181120-1800 ). > > Sorry, I am confused. Did you mean to say that the bug 542090 was fixed in > 4.10 but you still see the problem in 4.10? Hi Jay, sorry for the confusion. For me it was fixed by 4.10 and stayed fixed. I just gave the extra info that for me it was already fixed by the pre-release 4.10RC2 where you provided the fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=542090 . Bottom line: I don't encounter this problem anymore!
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.
