AutoValue 1.10.4 no longer works with GraalVM native image resource loading

[timothyg-stripe]

AutoValue 1.10.4 includes commit 3f69cd2 (intending to fix #1572), by explicitly enumerating possible URL schemes returned by Class.getResource and reading the URL appropriately. The code supports file and jar URLs, but GraalVM native image's resource loading support would return a resource URL like resource:/com/google/auto/value/processor/autovalue.vm, which is not supported:

java.lang.AssertionError: Template search logic fails for: resource:/com/google/auto/value/processor/autovalue.vm
    at com.google.auto.value.processor.TemplateVars.readerFromUrl(TemplateVars.java:148)
    at autovalue.shaded.com.google.escapevelocity.Template.parseFrom(Template.java:146)
    at autovalue.shaded.com.google.escapevelocity.Template.parseFrom(Template.java:140)
    at com.google.auto.value.processor.TemplateVars.parsedTemplateForResource(TemplateVars.java:125)
    at com.google.auto.value.processor.AutoValueTemplateVars.<clinit>(AutoValueTemplateVars.java:44)
    at com.google.auto.value.processor.AutoValueProcessor.processType(AutoValueProcessor.java:245)
    at com.google.auto.value.processor.AutoValueishProcessor.process(AutoValueishProcessor.java:442)

AutoValue 1.10.3 works correctly in GraalVM.

Recommended fixes:

• Add a special case in TemplateVars.readerFromUrl to call getResourceAsStream for the resource URL scheme, or
• If an unknown URL scheme is encountered, default to calling getResourceAsStream.

(Context: I am compiling Turbine as a GraalVM native image with built-in support for AutoValue.)

cc @eamonnmcmanus

[eamonnmcmanus]

Do you by chance have something I could run to reproduce the problem? Your proposed fixes seem reasonable but I would want to be able to test them.

I'm also a little puzzled because I believe we do run a graalified Turbine internally at Google. Perhaps @cushon might have some insights?

[timothyg-stripe]

@eamonnmcmanus Here you go: https://github.com/timothyg-stripe/auto-1783

It's as minimal as I could make it, but it's still rather large as it needs to include numerous Maven jars and rules_graalvm. The README has more details, including an appendix on overriding jars that you could use to test a locally built jar.

[cushon]

I'm also a little puzzled because I believe we do run a graalified Turbine internally at Google

We include some annotation processors in the internal GraalVM native-image for turbine, but AutoValue isn't included because it doesn't generate API and shouldn't need to run during annotation processing. We also use AutoValue with java_plugin.generates_api disabled.

@timothyg-stripe is your use-case that you have code that deliberately references generated AutoValue_ types in the public API, and so AutoValue needs to run during header compilation?

[timothyg-stripe]

Ah, that makes a lot of sense.

I'm not sure historically why we have AutoValue on generates_api = True. Currently for production builds, we typically have header compilation turned off and rely instead on ijar. The reason why we are interested in compiling Turbine with AutoValue built-in now is that, we have a pipeline to extract the "gensrc jar" from a Bazel build for IDEs, and Graal Turbine can run annotation processors faster than Javac/JavaBuilder (even with multiplex workers enabled).

[eamonnmcmanus]

Thanks for putting together the repro! I did finally manage to make it work with my own compiled jar, though given my Bazel ignorance it wasn't straightforward. :-)
A fix should be forthcoming, though it probably won't be useful to you until the next release.

[eamonnmcmanus]

The just-released 1.11.0 includes this change.

[timothyg-stripe]

Thank you for the quick fix!