search

google / dagger

A fast dependency injector for Android and Java.
https://dagger.dev
Apache License 2.0
17.44k stars 2.02k forks source link

MissingResourceException when running in a gradle project with many submodules #457

Closed kageiit closed 7 years ago

kageiit commented 8 years ago

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 https://github.com/google/auto/issues/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 commented 8 years ago

@cushon

kageiit commented 8 years ago

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 commented 8 years ago

@ronshapiro @cushon any updates or thoughts?

ronshapiro commented 8 years ago

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 commented 8 years ago

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 commented 7 years ago

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 https://github.com/google/google-java-format/commit/ba2a958fc7b2452779f99c9246ee0feb07f52815, 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 commented 7 years ago

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

kageiit commented 7 years ago

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 https://github.com/google/error-prone/issues/501

cushon commented 7 years ago

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 commented 7 years ago

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

ZacSweers commented 7 years ago

Yep we're good now on the crash