AutoService release 1.0-rc4

• Allow @autoservice to accept multiple service providers (c02f839)

Auto Common 0.9

• Add utility methods for writing @Generated annotations. (c9fd48f)
• Modified MoreTypes.asWildcard() to accept TypeMirror (c0637a4)
• Add an API to collect @SuppressedWarnings on all enclosing elements (506b566)
• Fix Visibility.ofElement() for ModuleElements for JDK 9. (2c035ce)
• Make AnnotationMirrors.getAnnotationValuesWithDefaults() return an ImmutableMap (39a48e7)

AutoValue Release 1.5.2

This releases fixes two problems with 1.5.1:

• Many javax.annotation.* classes were inadvertently included in autovalue-1.5.1.jar. They have been removed.

• @AutoAnnotation did not work well if the class javax.annotation.Generated did not exist, which is typically the case with Java 9.

AutoValue Release 1.5.1

This release is essentially the same as 1.5, except that it fixes #503. If you are using Java 9 and have seen a message like this:

warning: An exception occurred while looking for AutoValue extensions. No extensions will function.
This may be due to a corrupt jar file in the compiler's classpath.
Exception: java.util.ServiceConfigurationError: com.google.auto.value.extension.AutoValueExtension:
Provider com.google.auto.value.extension.memoized.MemoizeExtension could not be instantiated

then this release should fix it.

AutoValue Release 1.5

Functional changes since 1.4.1

• This release requires the compiler to be Java 8 or later. It can still generate Java 7 code using -source 7 -target 7, but the compiler itself must be a Java 8 compiler.

• The retention of the @AutoValue annotation has changed from SOURCE to CLASS. This means that it is possible for code-analysis tools to tell whether a class is an @AutoValue. AutoValue itself uses this to enforce the check that one @AutoValue class cannot extend another, even if the classes are compiled separately.

• It is now an error if @Memoized is applied to a method not inside an @AutoValue class.

• Type annotations are now handled more consistently. If @Nullable is a type annotation, a property of type @Nullable Integer will have that type used everywhere in the generated code. Associated bugs with nested type annotations, like Outer.@Inner, have been fixed.

Bugs fixed since 1.4.1

• @Memoized methods can now throw checked exceptions. Previously this failed because the exceptions were not copied into the throws clause of the generated override, so the call to super.foo() did not compile.

• The generated hashCode() method uses h = (int) (h ^ longProperty) rather than h ^= longProperty to avoid warnings about loss of precision.

• Annotations are not copied from an abstract method to its implementation if they are not visible from the latter. This can happen if the @AutoValue inherits the abstract method from a class or interface in a different package.

AutoValue Release 1.4.1

This release is essentially the same as 1.4.1. The only significant difference is that a workaround for an old Eclipse bug has been removed. That bug was fixed in Eclipse 4.5, which was released in June 2015. There was a concern that the workaround might have been interfering with correct behaviour.

If you need to use AutoValue with an older version of Eclipse, you will have to stay on AutoValue 1.4.

AutoValue Release 1.4

The contents of this release are identical to 1.4 RC3.

AutoValue Release 1.4 RC3

Functional changes since 1.4 RC2

• Builder setters now reject a null parameter immediately unless the corresponding property is @Nullable. Previously this check happened at build() time, and in some cases didn't happen at all.

• If a property foo() or getFoo() has a builder method fooBuilder() then the property can not now be @Nullable. An ImmutableList, for example, started off empty, not null, in this case, so @Nullable was misleading.

• Relatedly, the case where foo() is a nested @AutoValue class is now more similar to the case where it is an immutable collection. If you never add anything to fooBuilder() then you get an "empty" foo() at build() time, meaning whatever fooBuilder().build() returns.

• Access modifiers like protected are copied from builder methods to their implementations, instead of the implementations always being public. Change by @torquestomp.

• AutoAnnotation now precomputes parts of the hashCode that are constant because they come from defaulted members. This avoids warnings about integer overflow from tools that check that.

Extension API changes since 1.4 RC2

• Extensions can now return null rather than generated code. In that case the extension does not generate a class in the AutoValue hierarchy, but it can still do other things like error checking or generating side files.

Bugs fixed since 1.4 RC2

• GWT serialization tests are now run in prod mode. Change by @tbroyer.

• If @AutoValue Foo has a builder, we always generated two constructors, Builder() and Builder(Foo), but we only used the second one if Foo had a toBuilder() method. Now we only generate that constructor if it is needed. That avoids warnings about unused code.

• @AutoAnnotation now works when the annotation and the factory method are in the default (unnamed) package.

• In the hack to work around spurious exceptions when reading resource files, we now handle NullPointerException in addition to IOException.

• If a property has a name that is a Java keyword, for example getPackage() which defines a property called package, the Memoize extension will no longer generate code that doesn't compile.

@AutoFactory release 1.0-beta4

This version of AutoFactory adds support for @Nullable and varargs parameters on @AutoFactory constructors as well as Provider<> parameters to a create() method.

AutoValue Release 1.4 RC2

Functional changes since 1.4 RC1

• Generalized support for property builders. Now, in addition to being able to say immutableListBuilder() for a property of type ImmutableList<T>, you can say fooBuilder() for a property of an arbitrary type that has a builder following certain conventions. In particular, you can do this if the type of foo() is itself an @AutoValue class with a builder. (c8c00a9, 9949290)

• When an @AutoValue class Foo has a builder, the generated AutoValue_Foo.Builder has a constructor AutoValue_Foo.Builder(Foo). That constructor was never documented and is now private. If you want to make a Foo.Builder from a Foo, Foo should have an abstract method Builder toBuilder().

  This change was necessary so that generalized property-builder support could know whether or not the built class needs to be convertible back into its builder. (f6ee7ab)

Extension API changes since 1.4 RC1

• The Extension API is now a committed API, meaning we no longer warn that it is likely to change incompatibly. (8cbe76e)
• Beginning of guide to writing extensions (52e2335).

Bugs fixed since 1.4 RC1

• Support generic classes with @Memoized (9fa442d).
• Prepared for Java 9, where public classes are not necessarily accessible, and javax.annotation.Generated is not necessarily present. (44e9235)
• Functional tests for AutoAnnotation were accidentally excluded from the github sources. They have been restored. (3a8aeef)
• Added -implicit:class to several test methods in ExtensionTest to work around a compiler warning that causes test failures. (651aa3a)
• If a property is called oAuth(), allow its setter to be called setOAuth(x). Previously it had to be called setoAuth(x), which is still allowed. (ba55ca4)
• AutoValue now works correctly even if the version of AutoValue in the -classpath is older than the one in the -processorpath. (e1b3233)
• Builders now behave correctly when there is a non-optional property called missing. Previously a variable-hiding problem meant that we didn't detect when it wasn't set. (87085a0)

Miscellaneous

• Tests have been migrated from JUnit 3 to JUnit 4. (b541775)