If all the methods in an @AutoValue class are getters (getFoo() or isFoo()) then consider that each one defines a property called foo rather than getFoo. The user-visible change is that those names appear in the toString() of the generated class. The generated code is also a lot less surprising in this case. That's typically visible when you do code-completion on the AutoValue_Foo constructor in an IDE. The main motivation for this change is that we will want to support both bar(x) and setBar(x) when we add builders, and that means supporting both bar() and getBar() as setters. ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=78161706
A collection of source code generators for Java.
Java is full of code that is mechanical, repetitive, typically untested and sometimes the source of subtle bugs. Sounds like a job for robots!
The Auto subprojects are a collection of code generators that automate those types of tasks. They create the code you would have written, but without the bugs.
Save time. Save code. Save sanity.
AutoFactory - JSR-330-compatible factories
Latest version: 0.1-beta1
AutoService - Provider-configuration files for ServiceLoader
Latest version: 1.0-rc1
AutoValue - Immutable value-type code generation for Java 1.6+.
Latest version: 1.0-rc1
Common - Helper utilities for writing annotation processors.
Latest version: 0.2
Copyright 2013 Google, Inc. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.