Skip to content

Bazel 8 Migration - Dagger Bump& Patched Android Tools Javapoet Bump#207

Open
edwin-grabtaxi wants to merge 1 commit intomigration/bazel_8_main_branchfrom
migration/bazel_8_dagger_bump
Open

Bazel 8 Migration - Dagger Bump& Patched Android Tools Javapoet Bump#207
edwin-grabtaxi wants to merge 1 commit intomigration/bazel_8_main_branchfrom
migration/bazel_8_dagger_bump

Conversation

@edwin-grabtaxi
Copy link
Collaborator

rules_kotlin 2.1.2 (required for Bazel 8) bundles the Kotlin 2.1.0 compiler. This makes a Dagger upgrade mandatory and surfaces a classpath conflict between Dagger and all_android_tools_deploy.jar. Both are fixed together here.

Without this fix

  1. Kotlin 2.1.0 generates class metadata in format version 2.1.0. Dagger 2.46.1 internally uses kotlinx-metadata-jvm to read Kotlin class metadata at annotation processing time, but the version it ships with only understands metadata up to format 2.0.0, causing it to reject any Kotlin 2.1.0-compiled class:
java.lang.IllegalStateException: Unable to read Kotlin metadata due to unsupported metadata version.

Bumping to Dagger 2.53+ ships a newer kotlinx-metadata-jvm that understands the Kotlin 2.1.0 metadata format.

  1. After upgrading Dagger, the annotation processor classpath has two conflicting JavaPoet versions. all_android_tools_deploy.jar bundles JavaPoet 1.8.0 which shadows Maven's JavaPoet 1.13.0. ClassName.canonicalName() was only added as a method in JavaPoet 1.12.0, so when Dagger's ComponentProcessor calls it, it hits the older version first:
java.lang.NoSuchMethodError: 'java.lang.String com.squareup.javapoet.ClassName.canonicalName()'
    at dagger.spi.internal.shaded.androidx.room3.compiler.codegen.XClassName.<init>(XClassName.kt:54)
    at dagger.internal.codegen.ComponentProcessor.initialize(ComponentProcessor.java:100)

With this fix

  • Dagger annotation processing works correctly with Kotlin 2.1.0.
  • The JavaPoet version conflict is resolved. Databinding and Dagger share a compatible JavaPoet 1.13.0 on the annotation processor classpath.

Root cause

  • Dagger 2.46.1 is incompatible with Kotlin 2.1.0. The fix was introduced in Dagger 2.53 (Support Kotlin 2.1.0 google/dagger#4451). We upgrade to 2.59.1 (latest stable now).
  • Bazel 8 enforces strict classpath isolation. The upstream dagger_rules() macro defines the dagger-compiler java_plugin without explicitly listing dagger-spi and dagger itself as deps. Bazel 7 allowed these to leak through transitively, Bazel 8 doesn't.
  • all_android_tools_deploy.jar is a self-contained JAR that bundles JavaPoet 1.8.0. The canonicalName() method was added in JavaPoet 1.12.0. Any Dagger version that calls it will conflict with the bundled JavaPoet. We observed this with 2.59.1, and a similar conflict is reported for 2.57.1 (NoSuchMethodError in AggregateDepsTask due to JavaPoet/KotlinPoet version conflict with Hilt 2.57.1 google/dagger#4976).

Changes

  • Introduced rules/dagger/dagger.bzl. A local wrapper around the upstream dagger_rules() that explicitly adds dagger-spi and dagger as deps on the dagger-compiler plugin, working around Bazel 8's strict classpath isolation. We can't patch the upstream @bazel_common_dagger repository directly, so a local wrapper is the only practical option.
  • Bump Dagger 2.46.1 → 2.59.1 in rules/repositories.bzl.
  • Patch all_android_tools_deploy.jar to replace bundled JavaPoet 1.8.0 with JavaPoet 1.13.0. The JavaPoet API used by databinding (JavaFile, TypeSpec, MethodSpec, etc.) is stable across all versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant