Auto: the annotation processors that write your Java value classes

Four processors behind one repository

Auto is not a framework and it is not a runtime library. The README describes it as a collection of source code generators for Java, and its argument for existing is a short one: Java is full of code that is mechanical, repetitive, typically untested and sometimes the source of subtle bugs, which is what the repository says these generators are for.

The repository is split into four subprojects, and the tree shows each as its own directory. AutoValue generates immutable value-type code for Java 8 and later, and is the one most people meet first. AutoFactory generates factories compatible with JSR-330. AutoService writes the provider-configuration files that java.util.ServiceLoader reads, so you do not hand-maintain a META-INF/services file. Common holds the helper utilities for writing annotation processors, which is infrastructure for the other three rather than something you depend on directly.

Two more processors show up in the release history even though the README's subproject list does not mention them: AutoBuilder, the builder generator that sits alongside AutoValue, and AutoAnnotation, which generates annotation implementations. Their absence from the README list is worth noting if you are trying to work out what the repository contains, since the version numbers in the release history are not evenly distributed across the subprojects.

Generating code during compilation rather than at runtime

The mechanism is a standard annotation processor, which means the generated classes exist as real .class files on the classpath by the time your code compiles and runs. Nothing is reflected over at runtime, there is no proxy, and there is no base class you inherit from that you did not ask for. If you have a method that needs a builder and you did not write the builder by hand, the builder came out of the compiler.

That distinction matters when you are deciding whether to accept the dependency. The cost is paid in build configuration rather than in application code, because the build has to be told to run the processors, and in review habits, because a stack trace mentioning AutoValue_Foo is a generated class name and people need to know that before they go looking for the source.

AutoValue also relies on equals, hashCode and toString being derived from the declared abstract property methods rather than written out. The pattern is that you declare an abstract class with abstract accessor methods, annotate it, and the processor fills in the rest. The release history shows the project spending real effort on the awkward edges of that idea, including type-use annotations on generic properties and the exact case where an annotation such as Nullable on a setter parameter used to be dropped.

What the release notes fix, and what they break

AutoValue 1.11.1 from November 2025 is a bug-fix release and it reads like a list of things that were almost right. A crash caused by passing a class that does not exist to CopyAnnotations with an exclude argument is fixed. Type-use annotations on generic properties are now better preserved in generated builder setter parameters, and the same problem in AutoBuilder is fixed. A mix of required and optional parameters in a Kotlin data class with many properties could produce code that did not compile, and that is fixed too. Setters using boxed primitives for primitive properties now get a diagnostic rather than passing quietly.

The 1.11.0 release is the one that changes what you have to do. It removed support for generating Java 7 code from AutoValue, AutoAnnotation and AutoBuilder, and it names AutoValue 1.10.4 as the last version with Java 7 support. That is a real migration decision for anyone on an older toolchain, and the release says so in those terms. The same release stopped bundling the Kotlin metadata API, so client code that uses AutoBuilder to build Kotlin classes may need to add kotlinx-metadata-jvm explicitly.

AutoFactory 1.1.0 from November 2023 is a reminder that this repository moves at different speeds. It recognizes both javax.inject and jakarta.inject, prefers whichever is on the classpath, and adds a compiler option, -Acom.google.auto.factory.InjectApi, to force one or the other. It also improved the null-argument exception message to say how many arguments there are in total, which is the sort of detail that only matters once a project is large enough for the old message to be useless.

Comparing AutoValue against records and Lombok

The honest comparison to make first is against Java records, because that is where AutoValue's original justification has partly evaporated. A record gives you final fields, a canonical constructor, accessor methods, equals, hashCode and toString from the component list, with no dependency and no build configuration. For a simple immutable holder of three strings, records do the same job with less machinery.

What records do not give you is the extension surface around the value type. AutoValue's accessor methods are abstract methods you write, which means a generator can supply implementations for more than the standard set, and the builder generator, AutoBuilder, exists precisely to give you a builder for the generated class. If your value type needs a builder, custom derived methods or a wider set of generated behaviour, that is where paying for a processor still pays off. If it does not, the record is the shorter path.

Lombok is the other comparison, and the difference is in where the code comes from. Lombok modifies your source through its own annotation processing rather than generating a separate type, so the class you wrote is the class that compiles, with equals and getters written into it. AutoValue generates a separate AutoValue-prefixed class from an abstract declaration. Lombok's approach avoids a second type name; AutoValue's approach keeps your declared class abstract and puts the implementation somewhere the compiler owns. Neither is strictly better, and the choice usually comes down to what a team already has rather than on the merits.

What the repository tree does and does not tell you

The tree is short and it confirms the four-subproject split: common, factory, service and value as directories, plus a util directory, a build-pom.xml at the root, and the usual .github, .gitignore, CONTRIBUTING.md, LICENSE and README.md. There is no examples directory and no top-level documentation site, so the README plus the per-project pages are the whole public surface of the repository.

Licensing is the easy part: Apache License, Version 2.0, with the copyright line reading 2013 Google LLC. The README carries the full notice rather than linking to a file, and each subproject is published separately to Maven Central under the com.google.auto group, which is why the README attaches a version badge to each one. Depending on AutoValue does not drag in AutoService, because they are separate artifacts, which matters more than it sounds when you are adding one of them to a library that many people depend on. The coordinates you would put in a build file are `com.google.auto.value:auto-value`, `com.google.auto.factory:auto-factory`, `com.google.auto.service:auto-service` and `com.google.auto:auto-common`, and the README links each one to its artifact page on Maven Central:

https://mvnrepository.com/artifact/com.google.auto.value/auto-value
https://mvnrepository.com/artifact/com.google.auto.factory/auto-factory
https://mvnrepository.com/artifact/com.google.auto.service/auto-service
https://mvnrepository.com/artifact/com.google.auto/auto-common

Those pages are the quickest way to confirm which version of a given artifact is currently published, which matters in a repository that does not release every subproject at once.

The repository's last push was on 2026-09-21, and it is not archived. The pattern to understand is that releases are per-subproject rather than synchronized: the three most recent releases span AutoValue 1.11.1, AutoValue 1.11.0 and AutoFactory 1.1.0, published in November 2025, May 2024 and November 2023. That spacing is normal for infrastructure libraries and means you should check the specific artifact's own version rather than assuming the repository as a whole has a current release.

Editorial conclusion

Auto is the right choice when a Java project has a lot of small immutable classes, factories or service registrations and the team would rather not review generated-looking boilerplate in every pull request. It is the wrong choice for a project that has already moved its value types to Java records, since the main job AutoValue does is now a language feature, and it is worth knowing that Java 7 support was removed from AutoValue in the 1.11.0 release, with 1.10.4 named as the last version that still produced Java 7 output. Before adding it, check what your build has to do to run annotation processors and whether your compiler configuration can carry the extra dependencies, because that setup cost, not the generated code, is where projects actually get stuck.

Frequently asked questions

Official sources

1. google/auto on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases