DEV-1020 Declare the Guava version ShimmerDriver actually builds against

[marknolan]

Fixes DEV-1020. Split out of DEV-1013, which deliberately left this alone because it is consumer-visible.

One line of substance: guava:19.0 → guava:33.3.1-jre.

Why

The declared version has had no effect since grpc was added. io.grpc:grpc-all:1.71.0 pulls Guava transitively and wins on conflict resolution, so every build compiles and tests against 33.3.1-jre:

com.google.guava:guava:19.0 -> 33.3.1-jre
   Selection reasons:
      - By conflict resolution: between versions 33.3.1-jre, 33.3.1-android,
        19.0, 32.0.1-jre, 33.2.1-android, 30.1.1-android and 29.0-android

That version is not an internal detail. Guava is part of this module's public surface, so it is published as an api dependency and consumers compile against whatever our metadata states:

Where	What is exposed
ObjectCluster:77	public Multimap<String, FormatCluster> mPropertyCluster
ObjectCluster:665	public Multimap<String, FormatCluster> getPropertyCluster()
ShimmerObject:226	public BiMap<String, String> mSensorBitmaptoName
ShimmerObject:3611	public static BiMap<String,String> generateBiMapSensorIDtoSensorName(int)

So we were telling consumers to compile against a Guava eight years older than the one we build against.

Why corrected rather than removed

The ticket offered dropping the declaration and letting it arrive transitively. That is wrong here precisely because Guava is in the public API — it would leave a public-API dependency implicit and at the mercy of whatever grpc pulls next.

Android consumers are not shut out

Declaring the -jre coordinate does not force the JVM flavour on everyone. guava:33.3.1-jre publishes both jreApiElements and androidApiElements, so a Gradle consumer targeting Android still selects the android variant via org.gradle.jvm.environment. That dual-variant publishing is exactly what broke the Gradle 6.1 wrapper in DEV-1013 — Gradle's own error there enumerated both variants of 33.3.1-jre.

(A Maven consumer gets the -jre jar, since Maven ignores Gradle module metadata.)

Verified

• Resolution is unchanged — still 33.3.1-jre, and 19.0 no longer appears among the conflict-resolution candidates.
• The published metadata diff is exactly this and nothing else, in both variants and the POM:

-            "requires": "19.0"
+            "requires": "33.3.1-jre"
-      <version>19.0</version>
+      <version>33.3.1-jre</version>

• ShimmerDriver builds, 51 tests pass. ShimmerDriverPC builds (the path CI takes on this branch).

On severity — deliberately not overstated

The driver's own source still compiles cleanly when Guava is forced back to 19.0, so our code uses only long-stable Guava APIs. This is a correctness and clarity fix, not a live breakage.

One risk worth naming, though I could not reproduce it here (no Maven on this machine, so this is reasoning about Maven's algorithm rather than a demonstration): Maven mediates by nearest wins, not highest. A Maven consumer of our POM would therefore have taken our directly-declared 19.0 over grpc's transitive 33.3.1 — and since we also export grpc-all:1.71.0 as api, that pairs grpc 1.71 with Guava 19. Gradle consumers were never exposed to this, as Gradle takes the highest.

Independent of DEV-1013

Branched from master and touches only ShimmerDriver/build.gradle, which #297 does not touch. The two can merge in either order.

🤖 Generated with Claude Code

[JongChern]

looks good