• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1# AutoValue Changes
2
3**This document is obsolete.** For details of changes in releases since 1.5,
4see the [releases page](https://github.com/google/auto/releases) for the Auto
5project.
6
7## 1.4 → 1.5
8
9### Functional changes
10
11* A workaround for older Eclipse versions has been removed. If you need to use
12  an Eclipse version older than 4.5, you will need to stay on AutoValue 1.4.
13
14* The [retention](https://docs.oracle.com/javase/8/docs/api/java/lang/annotation/Retention.html)
15  of the `@AutoValue` annotation has changed from `SOURCE` to `CLASS`. This
16  means that it is possible for code-analysis tools to tell whether a class is
17  an `@AutoValue`. AutoValue itself uses this to enforce the check that one
18  `@AutoValue` class cannot extend another, even if the classes are compiled
19  separately.
20
21* It is now an error if `@Memoized` is applied to a method not inside an
22  `@AutoValue` class.
23
24* Type annotations are now handled more consistently. If `@Nullable` is a type
25  annotation, a property of type `@Nullable Integer` will have that type used
26  everywhere in the generated code. Associated bugs with nested type
27  annotations, like `Outer.@Inner`, have been fixed.
28
29### Bugs fixed since 1.4.1
30
31* `@Memoized` methods can now throw checked exceptions. Previously this failed
32  because the exceptions were not copied into the `throws` clause of the
33  generated override, so the call to `super.foo()` did not compile.
34
35* The generated `hashCode()` method uses `h = (int) (h ^ longProperty)` rather
36  than `h ^= longProperty` to avoid warnings about loss of precision.
37
38* Annotations are not copied from an abstract method to its implementation if
39  they are not visible from the latter. This can happen if the `@AutoValue`
40  inherits the abstract method from a class or interface in a different package.
41
42## 1.3 → 1.4
43
44*This is the last AutoValue version that compiles and runs on Java 6.* Future
45versions will require at least Java 8 to run. We will continue to generate code
46that is compatible with Java 7, so AutoValue can be used with `javac -source 7
47-target 7 -bootclasspath <rt.jar-from-jdk7>`, but using the `javac` from jdk8 or
48later.
49
50### Functional changes
51
52* Builder setters now reject a null parameter immediately unless the
53  corresponding property is `@Nullable`. Previously this check happened at
54  `build()` time, and in some cases didn't happen at all. This is the change
55  that is most likely to affect existing code.
56
57* Added `@Memoized`. A `@Memoized` method will be overridden in the generated
58  `AutoValue_Foo` class to save the value returned the first time it was called
59  and reuse that every other time.
60
61* Generalized support for property builders. Now, in addition to being able to
62  say `immutableListBuilder()` for a property of type `ImmutableList<T>`, you
63  can say `fooBuilder()` for a property of an arbitrary type that has a builder
64  following certain conventions. In particular, you can do this if the type of
65  `foo()` is itself an `@AutoValue` class with a builder. The default value of
66  `foo()`, if `fooBuilder()` is never called, is `fooBuilder().build()`.
67
68* If a property `foo()` or `getFoo()` has a builder method `fooBuilder()` then
69  the property can not now be `@Nullable`. An `ImmutableList`, for example,
70  starts off empty, not null, so `@Nullable` was misleading.
71
72* When an `@AutoValue` class `Foo` has a builder, the generated
73  `AutoValue_Foo.Builder` has a constructor `AutoValue_Foo.Builder(Foo)`. That
74  constructor was never documented and is now private. If you want to make a
75  `Foo.Builder` from a `Foo`, `Foo` should have an abstract method `Builder
76  toBuilder()`.
77
78  This change was necessary so that generalized property-builder support could
79  know whether or not the built class needs to be convertible back into its
80  builder. That's only necessary if there is a `toBuilder()`.
81
82* The Extension API is now a committed API, meaning we no longer warn that it is
83  likely to change incompatibly. A
84  [guide](https://github.com/google/auto/blob/master/value/userguide/extensions.md)
85  gives tips on writing extensions.
86
87* Extensions can now return null rather than generated code. In that case the
88  extension does not generate a class in the AutoValue hierarchy, but it can
89  still do other things like error checking or generating side files.
90
91* Access modifiers like `protected` are copied from builder methods to their
92  implementations, instead of the implementations always being public.
93  Change by @torquestomp.
94
95* AutoAnnotation now precomputes parts of the `hashCode` that are constant
96  because they come from defaulted methods. This avoids warnings about integer
97  overflow from tools that check that.
98
99* If a property is called `oAuth()`, its setter can be called
100  `setOAuth(x)`. Previously it had to be `setoAuth(x)`, which is still allowed.
101
102## Bugs fixed
103
104* AutoAnnotation now correctly handles types like `Class<? extends
105  Annotation>[]`. Previously it would try to create a generic array, which Java
106  doesn't allow. Change by @lukesandberg.
107
108* We guard against spurious exceptions due to a JDK bug in reading resources
109  from jars. (#365)
110
111* We don't propagate an exception if a corrupt jar is found in extension
112  loading.
113
114* AutoValue is ready for Java 9, where public classes are not necessarily
115  accessible, and javax.annotation.Generated is not necessarily present.
116
117* AutoValue now works correctly even if the version of AutoValue in the
118  `-classpath` is older than the one in the `-processorpath`.
119
120* Builders now behave correctly when there is a non-optional property called
121  `missing`. Previously a variable-hiding problem meant that we didn't detect
122  when it wasn't set.
123
124* If `@AutoValue class Foo` has a builder, we always generated two constructors,
125  `Builder()` and `Builder(Foo)`, but we only used the second one if `Foo` had a
126  `toBuilder()` method. Now we only generate that constructor if it is
127  needed. That avoids warnings about unused code.
128
129* `@AutoAnnotation` now works when the annotation and the factory method are in
130  the default (unnamed) package.
131
132## 1.2 → 1.3
133
134### Functional changes
135
136* Support for TYPE_USE `@Nullable`.
137  This is https://github.com/google/auto/pull/293 by @brychcy.
138
139* Restructured the code in AutoValueProcessor for handling extensions, to get
140  rid of warnings about abstract methods when those methods are going to be
141  implemented by an extension, and to fix a bug where extensions would not work
142  right if there was a toBuilder() method. Some of the code in this change is
143  based on https://github.com/google/auto/pull/299 by @rharter.
144
145* Added support for "optional getters", where a getter in an AutoValue Builder
146  can have type `Optional<T>` and it will return `Optional.of(x)` where `x` is
147  the value that has been set in the Builder, or `Optional.empty()` if no value
148  has been set.
149
150* In AutoValue builders, added support for setting a property of type
151  `Optional<T>` via a setter with an argument of type `T`.
152
153* Added logic to AutoValue to detect the confusing case where you think you
154  are using JavaBeans conventions (like getFoo()) but you aren't because at
155  least one method isn't.
156
157* Added a README.md describing EscapeVelocity.
158
159### Bugs fixed
160
161* Allow an `@AutoValue.Builder` to extend a parent builder using the `<B extends
162  Builder<B>>` idiom.
163
164* AutoAnnotation now factors in package names when detecting
165  overloads. Previously it treated all annotations with the same SimpleName as
166  being overload attempts.
167
168* Removed an inaccurate javadoc reference, which referred to an
169  artifact from an earlier draft version of the Extensions API. This is
170  https://github.com/google/auto/pull/322 by @lucastsa.
171
172## 1.1 → 1.2
173
174### Functional changes
175
176  * A **provisional** extension API has been introduced. This **will change**
177    in a later release. If you want to use it regardless, see the
178    [AutoValueExtension] class.
179
180  * Properties of primitive array type (e.g. `byte[]`) are no longer cloned
181    when read. If your `@AutoValue` class includes an array property, by default
182    it will get a compiler warning, which can be suppressed with
183    `@SuppressWarnings("mutable")`.
184
185  * An `@AutoValue.Builder` type can now define both the setter and builder
186    methods like so:
187
188    ```
189      ...
190      abstract void setStrings(ImmutableList<String>);
191      abstract ImmutableList.Builder<String> stringsBuilder();
192      ...
193    ```
194    At runtime, if `stringsBuilder()...` is called then it is an error to call
195    `setStrings(...)` afterwards.
196
197  * The classes in the autovalue jar are now shaded with a `$` so they never
198    appear in IDE autocompletion.
199
200  * AutoValue now uses its own implementation of a subset of Apache Velocity,
201    so there will no longer be problems with interference between the Velocity
202    that was bundled with AutoValue and other versions that might be present.
203
204### Bugs fixed
205
206  * Explicit check for nested `@AutoValue` classes being private, or not being
207    static. Otherwise the compiler errors could be hard to understand,
208    especially in IDEs.
209
210  * An Eclipse bug that could occasionally lead to exceptions in the IDE has
211    been fixed (GitHub issue #200).
212
213  * Fixed a bug where AutoValue generated incorrect code if a method with a
214    type parameter was inherited by a class that supplies a concrete type for
215    that parameter. For example `StringIterator implements Iterator<String>`,
216    where the type of `next()` is String, not `T`.
217
218  * In `AutoValueProcessor`, fixed an exception that happened if the same
219    abstract method was inherited from more than one parent (Github Issue #267).
220
221  * AutoValue now works correctly in an environment where
222    `@javax.annotation.Generated` does not exist.
223
224  * Properties marked `@Nullable` now get `@Nullable` on the corresponding
225    constructor parameters in the generated class.
226
227## 1.0 → 1.1
228
229### Functional changes
230
231  * Adds builders to AutoValue. Builders are nested classes annotated with
232    `@AutoValue.Builder`.
233
234  * Annotates constructor parameters with `@Nullable` if the corresponding
235    property methods are `@Nullable`.
236
237  * Changes Maven shading so org.apache.commons is shaded.
238
239  * Copies a `@GwtCompatible` annotation from the `@AutoValue` class to its
240    implementation subclass.
241
242### Bugs fixed
243
244  * Works around a bug in the Eclipse compiler that meant that annotations
245    would be incorrectly copied from `@AutoValue` methods to their
246    implementations.
247
248## 1.0 (Initial Release)
249
250  * Allows automatic generation of value type implementations
251
252    See [the AutoValue User's Guide](userguide/index.md)
253
254
255[AutoValueExtension]: src/main/java/com/google/auto/value/extension/AutoValueExtension.java
256