MissingResourceException when running in a gradle project with many submodules

[kageiit]

Dagger processor seems to crash sporadically when many parallel gradle modules in a project are being built.

This seems very similar to the issues observed in google/auto#365 which is related to reading resources and this long standing JDK issue: https://bugs.openjdk.java.net/browse/JDK-6947916

java.util.MissingResourceException: Can't find bundle for base name org.eclipse.jdt.internal.compiler.problem.messages, locale en_US
    at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1564)
    at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1387)
    at java.util.ResourceBundle.getBundle(ResourceBundle.java:845)
    at org.eclipse.jdt.internal.compiler.problem.DefaultProblemFactory.loadMessageTemplates(DefaultProblemFactory.java:218)
    at org.eclipse.jdt.internal.compiler.problem.DefaultProblemFactory.setLocale(DefaultProblemFactory.java:124)
    at org.eclipse.jdt.internal.compiler.problem.DefaultProblemFactory.<init>(DefaultProblemFactory.java:41)
    at org.eclipse.jdt.internal.compiler.problem.DefaultProblemFactory.<init>(DefaultProblemFactory.java:35)
    at org.eclipse.jdt.core.dom.CompilationUnitResolver.parse(CompilationUnitResolver.java:504)
    at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1202)
    at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:809)
    at com.google.googlejavaformat.java.Formatter.format(Formatter.java:115)
    at com.google.googlejavaformat.java.Formatter.formatSource(Formatter.java:157)
    at com.google.googlejavaformat.java.Formatter.formatSource(Formatter.java:144)
    at dagger.internal.codegen.SourceFileGenerator.generate(SourceFileGenerator.java:77)
    at dagger.internal.codegen.InjectBindingRegistry$BindingsCollection.generateBindings(InjectBindingRegistry.java:85)
    at dagger.internal.codegen.InjectBindingRegistry.generateSourcesForRequiredBindings(InjectBindingRegistry.java:175)
    at dagger.internal.codegen.ComponentProcessor.postProcess(ComponentProcessor.java:225)
    at dagger.shaded.auto.common.BasicAnnotationProcessor.process(BasicAnnotationProcessor.java:173)
    at com.facebook.buck.jvm.java.TracingProcessorWrapper.process(TracingProcessorWrapper.java:104)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:794)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:705)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1035)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1176)
    at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
    at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
    at com.sun.tools.javac.main.Main.compile(Main.java:523)
    ... 20 more
Caused by: java.io.IOException: Stream closed
    at java.util.zip.InflaterInputStream.ensureOpen(InflaterInputStream.java:67)
    at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:142)
    at java.io.FilterInputStream.read(FilterInputStream.java:133)
    at java.io.FilterInputStream.read(FilterInputStream.java:107)
    at java.util.Properties$LineReader.readLine(Properties.java:435)
    at java.util.Properties.load0(Properties.java:353)
    at java.util.Properties.load(Properties.java:341)
    at java.util.PropertyResourceBundle.<init>(PropertyResourceBundle.java:138)
    at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2687)
    at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1501)
    at java.util.ResourceBundle.findBundle(ResourceBundle.java:1465)
    at java.util.ResourceBundle.findBundle(ResourceBundle.java:1419)
    at java.util.ResourceBundle.findBundle(ResourceBundle.java:1419)
    at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1361)

[ronshapiro]

@cushon

[kageiit]

We have been able to work around this by forking dagger and disabling the java formatter part. It does not change the code functionally and just formats it, so it didnt have any impact.

It might be good to provide an apt argument to turn off java formatter due to this bug

[ZacSweers]

@ronshapiro @cushon any updates or thoughts?

[ronshapiro]

Can we get this fixed on the eclipse side of things? That would fix this issue for any google-java-format (and thereby dagger) user. I don't think not formatting is the way to solve this.

edit: I realize that might not be so simple, but I'm not sure what resource is needed to parse an AST.

[ZacSweers]

Agreed that not formatting isn't the ideal way to solve it, it's just a temporary patch on our end to de-flake our builds. I think the issue is IO reads in a multi-module project during APT exposes that JDK bug. There might not be much we can do about it without Java fixing it. I was thinking more of a solution around formatting before writing to disk, rather than writing once, reading back (where the error happens), and writing again. Sort of like AutoValue's Reformatter does. Thoughts?

[gk5885]

OK, so I did a bit of digging into this. First, it seems that while the stack trace contains GJF, the problem doesn't actually arise from formatting, but rather from ecj loading its own messages. Luckily, as of google/google-java-format@ba2a958, GJF doesn't use ecj anymore!

I chatted with @hzsweers and he's going to do a GJF build from HEAD and see if using that fixes their issue.

In either case, it seems like a new release of GFJ might be a good idea. I'm not sure exactly whose in charge of that release process but @cushon, @nglorioso and @ronshapiro seem like likely candidates.

[gk5885]

I talked with some people working on GJF and they're looking into cutting new release. google/google-java-format#111 is the tracking bug. As soon as that is resolved, we can cut a new dagger release and close this issue.

[kageiit]

GJF is using error prone compiler under the hood to format code now. Error prone bundles an unshaded guava version in their core jar that causes issues when it is put on the classpath by GJF. There is a related ticket open about it here google/error-prone#501

[cushon]

I'll cut a GJF release soon.

This is unrelated to google/error-prone#501 - Error Prone and GJF depend on the same version of javac, GJF does not depend on Error Prone.

[ronshapiro]

IIUC, this issue is no longer plaguing you, right? If it is, feel free to reopen this

[ZacSweers]

Yep we're good now on the crash