Auto Common Libraries v 0.8

Fixes

• Fix various incompatibilities between javac and ecj (89dcbae, 3d9fa63)

Notes

• Various javadoc improvements

AutoValue Release 1.4 RC1

Functional changes since 1.3

• @Memoized added, allowing non-property methods to be run-once and have the results cached.

  • @Memoized methods are guarded double-checked locking (a756ee6)

  • Very tentatively support using @LazyInit from github.com/google/error-prone as a just-in-time alternative
    to @Memoized)

    Note: This is internally tested, but is experimental, and doesn't have any serious testing in open-source.

• Ignore concrete methods in abstract-class builders when scanning to discover auto-value properties. (07d6fdd)
• Stop "pessimizing" arrays by pre-sizing them (nearly all VMs perform better without this) (82041d0)
• AutoValue now imports top-level types, and references nested types in a qualified way. (e.g. Foo.Bar)

Extension API changes since 1.3

• Introduce null-checks into generated classes' constructors, to guard against poorly crafted extensions. (660ea56)
• Guard against corrupt extension jar loading (4a052a8)

Bugs fixed since 1.3

• Fix @AutoAnnotation issue when passing in generic-array-parameter values using a collection. (82041d0)
• Some fixes inherited from an updated auto-common related to eclipse and ecj
• Guard against IOExceptions from reading resources from jars. Fixes #365
• Improved support for dealing with Java8 bytecode on the classpath (using ASM5)

Random stuff

• Source import statements re-ordered according to Google's new (simplified) standard format.
• Example code for builders uses "setFoo(Foo foo)" naming for clarity (not required in production code.)
• Faster jar creation on ubuntu during builds.

Auto Common Libraries v 0.7

Features/Changes

• Add a postRound(RoundEnvironment) method to BasicAnnotationProcessor, to ease
  post-processing (such as validation
• Switch some anonymous classes to named inner classes to make stack traces more obvious

Fixes

• Typo in exception message

Notes

• Javadoc improvements and other documentation fixes
• Code now conforms to Google's new import order format (static imports at the top, regular imports
  below, separated by one space, all lexically ordered within the two groups.
• Faster builds on ubuntu by using maven-jar-plugin 2.6 (2.5+ fixes the ubuntu bug)

AutoValue Release 1.3

Note: identical to 1.3-rc2.

Functional changes since 1.2

• Support for TYPE_USE @Nullable.
  This is #293 by @brychcy.
• Restructured the code in AutoValueProcessor for handling extensions, to get
  rid of warnings about abstract methods when those methods are going to be
  implemented by an extension, and to fix a bug where extensions would not work
  right if there was a toBuilder() method. Some of the code in this change is
  based on #299 by @rharter.
• Added support for "optional getters", where a getter in an AutoValue Builder
  can have type Optional<T> and it will return Optional.of(x) where x is
  the value that has been set in the Builder, or Optional.empty() if no value
  has been set.
• In AutoValue builders, added support for setting a property of type
  Optional<T> via a setter with an argument of type T.
• Added logic to AutoValue to detect the confusing case where you think you
  are using JavaBeans conventions (like getFoo()) but you aren't because at
  least one method isn't.
• Added a README.md describing EscapeVelocity.

Bugs fixed since 1.2

• Allow an @AutoValue.Builder to extend a parent builder using the <B extends Builder<B>> idiom.
• AutoAnnotation now factors in package names when detecting
  overloads. Previously it treated all annotations with the same SimpleName as
  being overload attempts.
• Removed an inaccurate javadoc reference, which referred to an
  artifact from an earlier draft version of the Extensions API. This is
  #322 by @lucastsa.
• The constructor of an @autovalue class that has a builder needs to have null checks if there are extensions, because in that case the constructor is package-private rather than private. Fixes #345.
• When scanning a Builder for referenced types, don't include non-abstract methods. The referenced types are used to determine the imports that will be needed by the implementing class, and that class never references non-abstract methods.

AutoValue Release 1.3-rc2

Bugs fixed

• The constructor of an @autovalue class that has a builder needs to have null checks if there are extensions, because in that case the constructor is package-private rather than private. Fixes #345.
• When scanning a Builder for referenced types, don't include non-abstract methods. The referenced types are used to determine the imports that will be needed by the implementing class, and that class never references non-abstract methods.

AutoValue Release 1.3-rc1

Functional changes

• Support for TYPE_USE @Nullable.
  This is #293 by @brychcy.
• Restructured the code in AutoValueProcessor for handling extensions, to get
  rid of warnings about abstract methods when those methods are going to be
  implemented by an extension, and to fix a bug where extensions would not work
  right if there was a toBuilder() method. Some of the code in this change is
  based on #299 by @rharter.
• Added support for "optional getters", where a getter in an AutoValue Builder
  can have type Optional<T> and it will return Optional.of(x) where x is
  the value that has been set in the Builder, or Optional.empty() if no value
  has been set.
• In AutoValue builders, added support for setting a property of type
  Optional<T> via a setter with an argument of type T.
• Added logic to AutoValue to detect the confusing case where you think you
  are using JavaBeans conventions (like getFoo()) but you aren't because at
  least one method isn't.
• Added a README.md describing EscapeVelocity.

Bugs fixed

• Allow an @AutoValue.Builder to extend a parent builder using the <B extends Builder<B>> idiom.
• AutoAnnotation now factors in package names when detecting
  overloads. Previously it treated all annotations with the same SimpleName as
  being overload attempts.
• Removed an inaccurate javadoc reference, which referred to an
  artifact from an earlier draft version of the Extensions API. This is
  #322 by @lucastsa.