Skip to content

[Bug] Annotation processor generated duplicated classes from dependency that also used autovalue #1734

Description

@Abacn

My Maven project is a java library, and it has another java library dependency, both my project and that dependency are under same package name.

Here is a minimum example.

My project has a single source file:

package org.apache.beam.sdk.io.gcp.spanner;

import com.google.auto.value.AutoValue;

@AutoValue
public abstract class DuplicateSpannerConfig {

  @AutoValue.Builder
  public abstract static class Builder {

    public abstract DuplicateSpannerConfig build();
  }
}

and declared a dependency

<properties>
    <autovalue.version>1.10.4</autovalue.version>
    <beam.version>2.54.0</beam.version>
    <maven-compiler-plugin.version>3.11.0</maven-compiler-plugin.version>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
  </properties>

  <dependencies>
    <dependency>
      <groupId>com.google.auto.value</groupId>
      <artifactId>auto-value</artifactId>
      <version>${autovalue.version}</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>com.google.auto.value</groupId>
      <artifactId>auto-value-annotations</artifactId>
      <version>${autovalue.version}</version>
    </dependency>
    <dependency>
      <groupId>org.apache.beam</groupId>
      <artifactId>beam-sdks-java-io-google-cloud-platform</artifactId>
      <version>${beam.version}</version>
    </dependency>
  </dependencies>

Run mvn clean compile

Expected: only AutoValue_DuplicateSpannerConfig in target/classes/org/apache/beam/sdk/io/gcp/spanner/ and target/classes

Actual: there are many AutoValue_* classes, seemingly regenerated from binaries in beam-sdks-java-io-google-cloud-platform in target/classes/org/apache/beam/sdk/io/gcp/spanner/.

Also, it seems there are specific conditions to trigger this bug:

  • If I my the @AutoValue class into an inner class, only my class was processed.

  • I also setup a same Gradle project, instead of using Maven, it works fine

The example is also available at https://github.com/Abacn/codesnippets/tree/master/AutoValueTest .

This was found by https://github.com/GoogleCloudPlatform/DataflowTemplates/actions/runs/8268070883 and reproduced locally. It is problematic for that project because the duplicated AutoValue_* classes does not handle nullable members correctly. For example, even though the decompiled dependency jar shows the @AutoValue abstract class has nullable members, e.g.

abstract @UnknownKeyFor @NonNull @Initialized Builder setCredentials(@UnknownKeyFor @NonNull @Initialized ValueProvider<@UnknownKeyFor @NonNull @Initialized Credentials> credentials);

and the AutoValue class in the dependency jar correctly marked it nullable

private @Nullable ValueProvider<Credentials> credentials;

nullable annotations get lost in the duplicate (generated) AutoValue class, unless my project duplicate the sources of the dependency jar (that is what currently did in DataflowTemplates/v1/.../gcp/spanner

Activity

  1. tbroyer commented on Mar 13, 2024

    @tbroyer
    Contributor

    This vaguely reminds me my 9-year-old blog post: https://blog.ltgt.net/most-build-tools-misuse-javac/

    Could it be that the Apache Beam sources are present in the compile class path? Javac could then possibly compile them and thus process them, but there likely is a workaround.

  2. Abacn commented on Mar 13, 2024

    @Abacn
    Author

    Could it be that the Apache Beam sources are present in the compile class path

    Apache Beam jar (compiled .class) is present in compile class path, though the source code does not.

    Current workaround is to duplicate the affected Beam sources into the project, so autovalue still generate duplicated class but with correct nullness handling

  3. eamonnmcmanus commented on Mar 14, 2024

    @eamonnmcmanus
    Member

    There are in fact source files in the Apache Beam jar: beam-jar-source-files.txt. I don't know if that is the source of the problem, though. It doesn't look as if any of the sources contain @AutoValue classes.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions