You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tell optimizers to assume that mightBeAndroid returns true.
That's a safe assumption only under Android, of course. But JVM users of Guava should almost certainly also be fine because they're extremely unlikely to be running a Proguard-style optimizer over their code, given that such optimizers are normally used only for Android apps. If this does cause you trouble, though, let us know, and we can arrange to publish different Proguard configurations for our Android and JRE flavors, at which point the problem would remain only for users who use `guava-android` under the _JVM_ (as is common for Robolectric tests) _and_ use an optimizer. And for now, that problem would be only a warning (from the fallback to `Unsafe`), with the eventual fate that the code would fall all the way back to `AtomicReferenceFieldUpdater` (when `Unsafe` is disabled)—which appears to perform equivalently to `Unsafe` on the JVM, anyway, IIRC :)
(Internally, we _already_ publish separate Proguard config files for our two flavors, so there, I'm changing only the Android one.)
The benefit of this CL is that it lets optimizers strip away the `VarHandle` code entirely. That's nice just for the code-size savings, but it's also nice for anyone who optimizes or otherwise analyzes the _result_ of an optimizer: It eliminates any need for such a person to include appropriate `-dontwarn` lines for our `VarHandle` usages.
That said, I would be nervous about trying to *re*-optimize the optimizer's output without including our Proguard configuration. (Including our Proguard configuration would prevent the error, since we already include a `-dontwarn` line. Note, though, that the optimizer may have to update the Proguard configuration so that it continues to refer to appropriate classes after renaming and other optimizations!) Optimizers are likely to do a good job with "simple" cases like the reflection in `AbtractFutureState`, but they might get things wrong in more complex classes.
RELNOTES=n/a
PiperOrigin-RevId: 743670573
0 commit comments