I should flesh this out more, but to just give the one example we know of offhand:
In guava-android, ImmutableList refers to RegularImmutableList, which of course refers to ImmutableList by being a subclass of it. ImmutableList contains an EMPTY_ITR field that refers to RegularImmutableList. That all works fine when users initialize ImmutableList first, as is "guaranteed" since #1977.
However, it sounds like GraalVM's build-time initialization can reflectively initialize classes in arbitrary order. That can lead to initializing RegularImmutableList first, producing problems like GoogleCloudPlatform/cloud-sql-jdbc-socket-factory#2178.
Additionally, we've gotten a couple bug reports over the years that suggest a bug in someone's Android toolchain that can likewise cause RegularImmutableList to be initialized first, producing the same kind of problem. [edit: Here's one such error.]
So we may want to be resilient to that, in the name of making GraalVM build-time initialization of Guava classes more likely to work (still not guaranteed!) and undetermined other optimizers not break things (also still not guaranteed!).
The workaround for ImmutableList is probably simple. (It's also possible that we could ship a native-image.properties or similar file in our jar or perhaps have one added to the community metadata for Guava. But I'm not sure we'd have any useful levers there other than "Don't allow ImmutableList (and thus its users) to be initialized at build time at all.")
But this general problem may exist more widely. It would be nice to detect it in more than just the (still useful!) cases that Error Prone does already. (Googlers can see some prior discussion in issue 35029034.) Maybe we can do that someday, but it would probably involve at least a bit of cleverness to do without significant false positives. (And one possibility is that we discover an unmanageable number of true positives....)
I should flesh this out more, but to just give the one example we know of offhand:
In
guava-android,ImmutableListrefers toRegularImmutableList, which of course refers toImmutableListby being a subclass of it.ImmutableListcontains anEMPTY_ITRfield that refers toRegularImmutableList. That all works fine when users initializeImmutableListfirst, as is "guaranteed" since #1977.However, it sounds like GraalVM's build-time initialization can reflectively initialize classes in arbitrary order. That can lead to initializing
RegularImmutableListfirst, producing problems like GoogleCloudPlatform/cloud-sql-jdbc-socket-factory#2178.Additionally, we've gotten a couple bug reports over the years that suggest a bug in someone's Android toolchain that can likewise cause
RegularImmutableListto be initialized first, producing the same kind of problem. [edit: Here's one such error.]So we may want to be resilient to that, in the name of making GraalVM build-time initialization of Guava classes more likely to work (still not guaranteed!) and undetermined other optimizers not break things (also still not guaranteed!).
The workaround for
ImmutableListis probably simple. (It's also possible that we could ship anative-image.propertiesor similar file in our jar or perhaps have one added to the community metadata for Guava. But I'm not sure we'd have any useful levers there other than "Don't allowImmutableList(and thus its users) to be initialized at build time at all.")But this general problem may exist more widely. It would be nice to detect it in more than just the (still useful!) cases that Error Prone does already. (Googlers can see some prior discussion in issue 35029034.) Maybe we can do that someday, but it would probably involve at least a bit of cleverness to do without significant false positives. (And one possibility is that we discover an unmanageable number of true positives....)