x.y.z-jre version has -android.jar artifact with missing -jre classes about guava

[jjohannes]

This is the expected behavior. Although, I know that it is confusing, because the version string with the -jre in it looks like it is the variant selection, but it is not (see explanation further down).

To select the JRE version in Android do what you have commented out:

dependencies.constraints {
  testImplementation("com.google.guava:guava") {
    attributes {
      attribute(
        TargetJvmEnvironment.TARGET_JVM_ENVIRONMENT_ATTRIBUTE,
        objects.named(TargetJvmEnvironment.STANDARD_JVM)
      )
    }
  }
}

It's not a "workaround", but a way to tell Gradle to select a different variant than your JVM environment's default.

Since 32.1.1, The -jre in the version number no longer has a meaning for Gradle.
That is, 33.0.0-jre and 33.0.0-android are the same from for Gradle. This way, there are no longer accidental switches from jre to android (or the other way around) by version conflict resolution. In previous versions, you could declare ...-jre but get ...-android, because of a higher ...-android version somewhere in the dependency graph.

Ideally, there won't be two versions 33.0.0-jre and 33.0.0-android but just 33.0.0. But I guess that schema needs to be kept for Maven consumers. I fully understand why encoding the "variant" in the version was chosen back in the day. But strictly speaking it is "wrong". The version conflict resolution of tools (both Gradle and Maven) is not made for using the version like this and that leads to follow up confusion.

Because of the above, it gets confusing when you look at the resolution result of Gradle. In your example it says that it resolved to -> 33.0.0-jre. But as the -jre here has no meaning, it could have been 33.0.0-android as well and the result would be the same. What matters is the variant it resolves to and the Jar file that's behind that variant. Unfortunately, the dependencies tasks does not show that. It would be nice if the dependencies task would have some kind of "extended mode" that also shows the variants and files.

You can use dependencyInsight to get the full picture (almost, as this also does not show the Jar file):

$ gradle dependencyInsight --configuration releaseUnitTestRuntimeClasspath --dependency com.google.guava:guava

> Task :dependencyInsight
com.google.guava:guava:33.0.0-jre
  Variant androidRuntimeElements:
    | Attribute Name                                  | Provided     | Requested    |
    |-------------------------------------------------|--------------|--------------|
    | org.gradle.dependency.bundling                  | external     |              |
    | org.gradle.jvm.version                          | 8            |              |
    | org.gradle.libraryelements                      | jar          |              |
    | org.gradle.status                               | release      |              |
    | org.gradle.category                             | library      | library      |
    | org.gradle.jvm.environment                      | android      | android      |
    | org.gradle.usage                                | java-runtime | java-runtime |
    | com.android.build.api.attributes.AgpVersionAttr |              | 8.2.1        |
    | com.android.build.api.attributes.BuildTypeAttr  |              | release      |
   Selection reasons:
      - By constraint
      - By conflict resolution: between versions 33.0.0-jre and 31.1-jre

Here we have the clues Variant androidRuntimeElements and org.gradle.jvm.environment = android

---

With this comment, I only want to explain the situation. I don't want to say that things are perfect as they are. But I am not sure what a concrete next action would be. Things I see:

1. On the Guava side, it would be good to get rid of the -jre and -android in the version at some point, but I am not sure if and how that could ever be possible.
2. On the Gradle side, I think there is room for improving what the dependency task reports.
3. ...and in the DSL for defining attribute values (attributes { attribute(TargetJvmEnvironment.TARGET_JVM_ENVIRONMENT_ATTRIBUTE, objects.named(TargetJvmEnvironment.STANDARD_JVM)) } is very clumsy and the variant selection mechanisms are still quite hard to understand if a build user needs to interact with them directly (as it is the case here).

[cpovirk]

Sorry, @TWiStErRob, for the trouble with this, and thanks again, @jjohannes, for jumping in with an explanation.

I still need to do more about this class of problem. My recent work has been mostly to add APIs like Sets.toImmutableSet to the Android flavor so that it differs from the JRE flavor mostly just in implementation details, rather than in public API. So far, I've added APIs as package-private, and I'm waiting to see if users encounter problems when they adopt 33.0.0. If no one reports problems, then I expect to make the APIs public and add more such APIs, at which point things might work for you even when Gradle selects the Android variant. (Thanks for being among those to test 33.0.0, and sorry again.)

I think you're right that this is fundamentally the same as #6801, so I'll try to consolidate things back there.