google / auto Goto Github PK

View Code? Open in Web Editor NEW

10.4K 341.0 1.2K 36.97 MB

A collection of source code generators for Java.

License: Apache License 2.0

Java 99.88% Shell 0.04% Kotlin 0.08%

auto's Introduction

Auto

A collection of source code generators for Java.

Overview

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.

Subprojects

AutoFactory - JSR-330-compatible factories
AutoService - Provider-configuration files for ServiceLoader
AutoValue - Immutable value-type code generation for Java 7+.
Common - Helper utilities for writing annotation processors.

License

Copyright 2013 Google LLC

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.

auto's People

Contributors

Stargazers

Watchers

Forkers

cgruber gk5885 qz267 sgoldfed at13 eamonnmcmanus lowasser ocean1208 steveswing hyamamoto danielkutik sinsixx asylumcorp brownman90 luigi-agosti framiere creativepsyco bevan8909 camerondavison changyoonjai h87kg sleyzerzon vivekasingh ghosthamlet createinfo caprice suspend0 ashgupta1489 luisyang daldei khalidelsayed cybernetics spencerx ryanabc chineseta alex-google feverq cnh rtannenbaum leo1205 fisheye-123 rduboveckij hnlshzx zhaog oztc toanpv jmxt3 alisheikh noiroi solcott alexander-kim amnon cgrushko johngmyers irabc imace gjtsusi danielnorberg dflemstr jbgi gandhiramu dgu123 alicederyn pralgomathic mattprecious javachengwc vpozhidaev goodev ld1987 rejasupotaro sahitya-pavurala os-corp sunjue-heavyrain chouxiaozi l371559739 weidagang jstockdi hongjunli suntoe duoduogroup babsher todotobe1 tandan330 cypressious dankurka felipecsl ofdata andersonblough chengjf0526 rdtorres geekcheng gjoseph sunbeansoft sarod tbroyer hyh888 wfxiang08 quyixia rharter charlesmunger

auto's Issues

AutoFactory: optional parameters

Factories are often used because there are too many parameters and/or options to specify them:
new Factory().setBla(2).setFoo("yes").create();

instead of new Bar(2, "yes");

Can we specify some parameters as "optional", which will cause setter methods to be generated instead of a create() method which accepts all parameters?

Suggestion:

class Bar {
  @AutoFactory(validate = validate)
  public Bar(@Optional(default = getBla) D bla, R required) { ... }

  /**
   * Write any assertions that the factory's create() will call.
   */
  static void validate(D bla, R required) {
    Preconditions.assertState(...);
  }

  /**
   * Create a value for "default" if not supplied
   */
  static D getBla(R required) {
    return new Proxy(C, R);  // just an example!
  }
}

will generate

class BarFactory {
  private D bla = null;

  @Inject
  public BarFactory() {
  }

  public BarFactory setBla(D bla) {
    this.bla = bla;
    return this;
  }

  public Bar create(R required) {
    if (bla == null) {
      bla = Bar.getBla();
    }
    Bar.validate(D, R);
    return new Bar(D, R);
  }
}

Usage:

BarFactory bf = new BarFactory().setBla(b).create(R);

BarFactory bf = new BarFactory().create(R); // Uses default for "bla"

could you update your lastest library in maven?

the file seperator bug is on the fly in maven repo.

AutoValue: generate Comparable.compareTo()

It will be good for AutoValue to generate the compareTo method if the class implements Comparable. Because using sorted collections with improperly implemented Comparable objects will result in unexpected behavior and hard to track bugs.

From Comparable's Javadoc:

It is strongly recommended (though not required) that natural orderings be consistent with equals. This is so because sorted sets (and sorted maps) without explicit comparators behave "strangely" when they are used with elements (or keys) whose natural ordering is inconsistent with equals. In particular, such a sorted set (or sorted map) violates the general contract for set (or map), which is defined in terms of the equals method.

For example, if one adds two keys a and b such that (!a.equals(b) && a.compareTo(b) == 0) to a sorted set that does not use an explicit comparator, the second add operation returns false (and the size of the sorted set does not increase) because a and b are equivalent from the sorted set's perspective.

AutoValue for Java 8 Interfaces

@AutoValue
public interface Human {
  static Human create(String name) {
    return new AutoValue_Human(name);
  }

  String name();
}

AutoValue field names (occur in toString implementation also) should omit "get" prefix in getter names

@AutoValue
class Foo {
    abstract int getBar();
}

I expect foo.toString be "Foo{bar=0}", not "Foo{getBar=0}"

AutoFactory / Dagger integration requires fully qualified types

I found another strange issue but it seems there is a problem with dagger / autofactory integration.

I always always have to end up tying out the fully qualified so that dagger can find the factory at annotation / compile time.

@Inject
com.company.FooFactory

instead of being able to do

@Inject
FooFactory

I'm not sure if it's the way I'm compiling my projects also but wanted to track it here and see if you guys think it's a Dagger issue or an Auto issues, either way even if it's my environment it should try to be fixed from somewhere to prevent the issue from happening again in the future from the library side of things.

Support overriding factory methods that come from generic superclasses/interfaces.

When a factory method is inherited from a generic class/interface, generated auto factory will use type parameter name (e.g. T) rather than the substituted type. For example, given this code:

class MyClass {

  @AutoFactory(implementing = MyFactory.class)
  MyClass(@Provided String s, Integer i) {}

  interface MyFactory
      extends GenericFactory<MyClass, Integer> {}

  interface GenericFactory<T,S> {
    T make(S arg);
  }
}

Generated factory will contain this method

    public MyClass make(S arg) {
      return create(arg);
    }

Add @AutoForward for forwarding classes

This would remove the boilerplate from writing forwarding classes. @AutoForwarding classes would require a delegate() method and call delegate().method(...) for all methods, except for overridden methods which implementors could provide.

Annotate constructor parameters with `@Nullable` where relevant

This was already raised in the discussion of #73 , but what is the state of making the constructor arguments nullable for properties which getters are annotated with @Nullable ?
This makes total sense from a user standpoint IMO (e.g. for static analysis), and wouldn't present as many tricky decisions as equals() would: simply annotate the parameter with the annotation the getter was annotated with (and no new dependency pulled either).

checkout impossible on windows

It isn't possible to checkout the git repository on windows due to a directory with a reserved name.

$ git checkout -f
fatal: cannot create directory at 'factory/src/test/resources/aux': Invalid argument

Xor as AutoValue.hashCode for Entry-like classes

It is Map.Entry interface explicit requirement, also should be faster.

AutoValue: annotations to ignore / mask a field in generated toString

Some field value may be confidential or not wanted at all in toString result.
Maintaining a custom toString() is cumbersome, so I would like two new method annotations :

@ToStringIgnored
@ToStringMask("<CONFIDENTIAL>")

AutoFactory: Ignore non annotated constructors

I think AutoFactory should ignore constructors where @provided annotations don't exist or at least provide an option to tell auto factory not to turn a constructor method into a factory.

The biggest use case is that sometimes you may have a private constructor for specific use cases. Right now AutoFactory aggressively attempts to turn the private constructor into a create method for no real reason. I've also come across a use case where a child wants to use a parent constructor (when both the child and parent both have auto factories) but the child wants to use a specific non managed constructor on the parent.

AutoFactory: Lazy Fields in Parents

http://stackoverflow.com/questions/25539899/dagger-google-auto-factory-deal-with-mix-of-lazy-and-provided-fields

Hey there I posted this question in StackOverflow but it seems like a big oversight or an explanation is needed, here's the example again.

public class Person {

   @Lazy<Foo> protected mLazyFoo;

}

@AutoFactory(
   className = "ManFactory"
)
public class Man extends Person {

    Private Hammer mHammer;

    Man(@Provided Hammer hammer) {
       mHammer = hammer;
    }

}

// mLazyFoo is null!!!!!
Man man = ManFactory.create();

How exactly would you deal with the problem of mLazyFoo being null? Adding a another provided to add Foo will not work at all as it will then be not be lazy then. The only valid method I could think about is the injector needs to inject fields onto the man object, then call the provided constructor.

Structurally I could add another mLazyFoo on the Man, but then we're going to get into duplicate field names then for every subclass (which is sort of code smelly).

AutoFactory does not support constructors that throw checked exceptions.

Checked exceptions declared by the constructor should be added to the throw list for the generated create() method.

Common v0.2 in Maven central depends on SNAPSHOT

http://repo1.maven.org/maven2/com/google/auto/auto-common/0.2/auto-common-0.2.pom

<parent>
  <groupId>com.google.auto</groupId>
  <artifactId>auto-parent</artifactId>
  <version>1.0-SNAPSHOT</version>
</parent>

autovalue fails when runnning `mvn verify`

when running mvn verify from the auto/value project gives this:

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running com.google.auto.value.processor.AbstractMethodExtractorTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.114 sec
Running com.google.auto.value.processor.AbstractMethodListerTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
Running com.google.auto.value.processor.CompilationErrorsTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.052 sec
Running com.google.auto.value.processor.CompilationTest
Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.636 sec
Running com.google.auto.value.processor.JavaTokenizerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running com.google.auto.value.processor.TemplateVarsTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running com.google.auto.value.processor.TypeSimplifierTest
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.071 sec <<< FAILURE!
testTypeSimplifierErrorTypes(com.google.auto.value.processor.TypeSimplifierTest)  Time elapsed: 0.024 sec  <<< FAILURE!
junit.framework.AssertionFailedError: [/var/folders/jk/0ylhts1j1szcnnf7pnr1wykm0000gn/T/1408099842353-0/ExtendsUndefinedType.java:1: error: cannot find symbol
public class ExtendsUndefinedType extends MissingType {}
                                          ^
  symbol: class MissingType, /var/folders/jk/0ylhts1j1szcnnf7pnr1wykm0000gn/T/1408099842353-0/ExtendsUndefinedType.java:1: error: cannot find symbol
public class ExtendsUndefinedType extends MissingType {}
                                          ^
  symbol: class MissingType] expected:<[]> but was:<[/var/folders/jk/0ylhts1j1szcnnf7pnr1wykm0000gn/T/1408099842353-0/ExtendsUndefinedType.java:1: error: cannot find symbol
public class ExtendsUndefinedType extends MissingType {}
                                          ^
  symbol: class MissingType]>
    at junit.framework.Assert.fail(Assert.java:57)
    at junit.framework.Assert.failNotEquals(Assert.java:329)
    at junit.framework.Assert.assertEquals(Assert.java:78)
    at junit.framework.TestCase.assertEquals(TestCase.java:244)
    at com.google.auto.value.processor.TypeSimplifierTest.doTestTypeSimplifier(TypeSimplifierTest.java:170)
    at com.google.auto.value.processor.TypeSimplifierTest.doTestTypeSimplifierWithSources(TypeSimplifierTest.java:111)
    at com.google.auto.value.processor.TypeSimplifierTest.testTypeSimplifierErrorTypes(TypeSimplifierTest.java:99)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at junit.framework.TestCase.runTest(TestCase.java:176)
    at junit.framework.TestCase.runBare(TestCase.java:141)
    at junit.framework.TestResult$1.protect(TestResult.java:122)
    at junit.framework.TestResult.runProtected(TestResult.java:142)
    at junit.framework.TestResult.run(TestResult.java:125)
    at junit.framework.TestCase.run(TestCase.java:129)
    at junit.framework.TestSuite.runTest(TestSuite.java:255)
    at junit.framework.TestSuite.run(TestSuite.java:250)
    at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
    at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
    at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
    at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

Running com.google.auto.value.processor.VelocityClassLoaderTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.278 sec

this is building on commit hash: 23a8e52

this also fails if you run from the root project: mvn -f build-pom.xml verify

Factory ProcessorModule not picked up with dagger 1.2.1

I'm still quite new to dagger and the auto tools (great libs btw!) and I'm trying out auto factory. However I get an error that I don't know how to fix? I use dagger 1.2.1. and afaik I'm doing nothing fancy. (just annotating a class with autofactory). All these types seem to be defined by the ProcessorModule, so I'm a bit puzzled as to why they're not picked up.

java: java.lang.IllegalStateException: Errors creating object graph:
javax.annotation.processing.Messager could not be bound with key javax.annotation.processing.Messager required by class com.google.auto.factory.processor.AutoFactoryProcessor
javax.lang.model.util.Elements could not be bound with key javax.lang.model.util.Elements required by class com.google.auto.factory.processor.AutoFactoryProcessor
javax.lang.model.util.Types could not be bound with key javax.lang.model.util.Types required by class com.google.auto.factory.processor.AutoFactoryProcessor
javax.annotation.processing.Filer could not be bound with key javax.annotation.processing.Filer required by class com.google.auto.factory.processor.FactoryWriter

Incorporate comments from pull #136 into the codebase.

Some additional review comments were put into #136 which was purely a sync commit pulling change from internal google source.

integrate the review comments into a commit/CL.

Factory generation mixups when more than 1 factory in same package with implementing interface

When 2 or more types with each their own autofactory and each autofactory with their own interface is declared, then each generated autofactory class contains the implementation of all autofactory interfaces.

Document Eclipse Integration

Using AutoValue in Eclipse results in Errors in the Workspace as eclipsec does not generate the Auto-Classes when running the incremental build. Perhaps you can provide some best-practices how to circumvent this problem.

There are some Tips out in the wild, like http://www.codeaffine.com/2014/03/04/using-the-autovalue-code-generator-in-eclipse/, but I think for most users the error will be enough of a showstopper to think the library (and not eclipse) is buggy.

AutoFactory has wrong maven info in README

Looks like it should be

<dependencies>
  <dependency>
    <groupId>com.google.auto.factory</groupId>
    <artifactId>auto-factory</artifactId>
    <version>${autofactory.version}</version>
    <optional>true</optional>
  </dependency>
</dependencies>

Factory source generation fails when a type of <Foo>Factory is already present.

Code generation should not blindly take the name of the type that needs to be generated and add 'Factory' to it. A check should be made if a type of the same name already exist and take appropriate action (eg inform user or change it's own name).

Test failures under JDK8

It looks like auto fails to pass tests when run under JDK8, with the release imminent it might be good to get this resolved before a 1.0 release:

Running com.google.auto.factory.processor.AutoFactoryDeclarationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.847 sec
Running com.google.auto.factory.processor.AutoFactoryProcessorTest
Tests run: 20, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 10.148 sec <<< FAILURE!
providedOnMethodParameter(com.google.auto.factory.processor.AutoFactoryProcessorTest)  Time elapsed: 0.132 sec  <<< FAILURE!
java.lang.AssertionError: Compilation was expected to fail, but contained no errors
  at org.truth0.Truth$1.fail(Truth.java:57)
  at com.google.testing.compile.JavaSourcesSubject$CompilationClause.failsToCompile(JavaSourcesSubject.java:106)
  at com.google.auto.factory.processor.AutoFactoryProcessorTest.providedOnMethodParameter(AutoFactoryProcessorTest.java:154)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:491)
  at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
  at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
  at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
  at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
  at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
  at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
  at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
  at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:491)
  at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
  at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
  at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
  at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
  at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

providedButNoAutoFactory(com.google.auto.factory.processor.AutoFactoryProcessorTest)  Time elapsed: 0.12 sec  <<< FAILURE!
java.lang.AssertionError: Compilation was expected to fail, but contained no errors
  at org.truth0.Truth$1.fail(Truth.java:57)
  at com.google.testing.compile.JavaSourcesSubject$CompilationClause.failsToCompile(JavaSourcesSubject.java:106)
  at com.google.auto.factory.processor.AutoFactoryProcessorTest.providedButNoAutoFactory(AutoFactoryProcessorTest.java:143)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:491)
  at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
  at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
  at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
  at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
  at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
  at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
  at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
  at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:491)
  at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
  at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
  at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
  at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
  at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)


Results :

Failed tests:   providedOnMethodParameter(com.google.auto.factory.processor.AutoFactoryProcessorTest): Compilation was expected to fail, but contained no errors
  providedButNoAutoFactory(com.google.auto.factory.processor.AutoFactoryProcessorTest): Compilation was expected to fail, but contained no errors

Tests run: 21, Failures: 2, Errors: 0, Skipped: 0

Factory source generation fails when a method of create(Foo foo) is already present in implemented interface

Creating a factory with an interface that already contains the would be generated method fails. The code generation should only create the implementation of said method.

How does this differ from Kohsuke's annotation processor?

Documentation contrasting with http://search.maven.org/#artifactdetails%7Corg.kohsuke.metainf-services%7Cmetainf-services%7C1.5%7Cjar would be helpful.

AutoValue and OrmLite union

First of all, thanks for great idea. I love your approach :)

My question is follow...Is there any way to combine AutoValue together with OrmLite?

Best regards.

AutoValue: (Optionally) Add private no-arg constructor to generated classes

Some libraries require classes to have a private no-arg constructor, but there is currently no way of providing one for AutoValue's generated classes.

In my case, I am using Kryo (https://github.com/EsotericSoftware/kryo) to serialize/deserialize objects, and it requires that they have a no-arg constructor for deserialization. This means that currently I can't use AutoValue for classes that I intend to serialize.

Ideally, this should be configurable (provide a parameter to that annotation?).

Documentation not accessible behind firewalls

Would you move your documentation from Google Docs to a more accessible location? Corporate firewalls often block Google Docs.

Eliminate the use of checkstyle

It seems obvious to me that checkstyle is causing us a huge amount of work for very little benefit. It is also impossible to configure it to respect Google Style exactly. I suggest that we change the Auto project so that it does not invoke checkstyle as part of the standard Maven build.

Consider using Guava helpers in an AutoValue's equals, hashCode, and toString methods.

I think Guava's Objects.equal, Objects.hashCode, and Objects.toStringHelper would simplify both code generation and the generated code.

If you intentionally avoid the Guava helpers, can you explain why? Maybe the current implementation runs faster, or you don't want to introduce an AutoValue -> Guava dependency.

ide instructions in readme

The readme instructions don't mention enabling annotation processing in your ide, and even after doing so my code compiles but intellij 13 CE (OSX) cannot find the generated classes, making the editor show compiler errors.

These instructions for eclipse look promising, but also a pain to have to set up manually.
http://www.codeaffine.com/2014/03/04/using-the-autovalue-code-generator-in-eclipse/

Btw I'm glad to have an alternative to lombok! I like the feature set but we've been plagued with compatibility issues with new ide/java/lombok versions.

Auto-value test failure on Apple JVM 1.6 on a mac.

The CompilationTest fails on mac's 1.6 java virtual machine. It's unclear why, but it seems like it's building an invalid AutoValue_Baz lacking a return type, though I suspect that is a masking error.

Commit (though I had to bump pom version numbers too, so this failure is only seen when ref 8593961 is applied and the build proceeds to run this test:

commit 46146a1f30e8ef8825ea1aaa33924e7aa1b41d5d
Author:     Éamonn McManus <[email protected]>
AuthorDate: Tue Jun 17 18:39:10 2014 -0700
Commit:     Christian Edward Gruber <[email protected]>
CommitDate: Wed Jun 18 01:49:17 2014 -0700

    Add a test to AutoValue's CompilationTest that uses compile-testing's generatesSources clause to check that the generated co~
    -------------
    Created by MOE: http://code.google.com/p/moe-java
    MOE_MIGRATED_REVID=68848125

Here's the failure. This is all done in memory, so

testCompilation(com.google.auto.value.processor.CompilationTest)  Time elapsed: 0.074 sec  <<< ERROR!
java.lang.IllegalStateException: error while parsing:
foo/bar/AutoValue_Baz.java:7: invalid method declaration; return type required

        at com.google.testing.compile.Compilation.parse(Compilation.java:100)
        at com.google.testing.compile.JavaSourcesSubject$SuccessfulCompilationBuilder.generatesSources(JavaSourcesSubject.java:261)
        at com.google.auto.value.processor.CompilationTest.testCompilation(CompilationTest.java:99)

AutoFactory integration test wrong name

bad c/p. auto factory integration test is called auto-value integration test.

Provide OSGi meta data

To ease using e.g. AutoValue in an OSGi environment it would help if the released jar had a MANIFEST.MF containing OSGi meta data. The library/bundle could then be provisioned in a p2 repository.

The Bundle Plugin for Maven is one option to generate the meta data. Given that the number and names of public packages of the auto libraries don't change often, the maintenance effort should be very low.

Annotation for methods(fields) to be excluded from equals/hashcode

In many cases there is necessary to exclude some fields of class from comparing in equals and from generation of hashCode.

So it would be good to have annotation to mark methods to be excluded from AutoValue generated equals/hashCode.

For example:

@AutoValue
public abstract class Foo {
    @ExcludeAnnotation public abstract Bar bar();
    public abstract Baz baz();
}

How do I find the Maven artifacts?

I cannot find them on Maven Central. Where are they hosted?

AutoFactory: factories are final, prevent use of Mockito

Generated factories are final, which means they cannot be mocked using Mockito.
Even though they're designed for injection, passing a mock of such factory is so much easier than providing a test module and messing around with the DI's graph.

mvn install fails

$ mvn install
...
[INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project functional: Compilation failure
[INFO] [ERROR] /home/gaul/work/auto/value/target/it/functional/src/main/java/PackagelessValueType.java:[55,12] constructor AutoValue_PackagelessValueType in class AutoValue_PackagelessValueType cannot be applied to given types;
[INFO] [ERROR] required: java.lang.String,int,java.util.Map<java.lang.String,java.lang.Long>
[INFO] [ERROR] found: int,java.lang.String,java.util.Map<java.lang.String,java.lang.Long>
[INFO] [ERROR] reason: actual argument int cannot be converted to java.lang.String by method invocation conversion
...

$ java -version
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

Inspection of generated value/target/it/functional/src/main/java/PackagelessValueType.java reveals reversed integer and string arguments.

Generated equals(Object) method parameter should be @Nullable

In AutoValue,

  @Override
  public boolean equals(Object o) {
  // ...

should be

  @Override
  public boolean equals(@Nullable Object o) {
  // ...

I think it's better form, and without it, AutoValue doesn't play nicely with Guava's AbstractPackageSanityTests.

Fix url in the last page of presentation slide.

At the bottom of the document (README.md), there is a link to a wonderful slide presentation:

"This slide presentation walks through several competing solutions to this problem and shows why we considered them insufficient."

(Slide: urtl https://docs.google.com/presentation/d/14u_h-lMn7f1rXE1nDiLX0azS3IkgjGl5uxp5jGJ75RE/edit#slide=id.g2a5e9c4a8_0243)

The last slide of the presentation shows "AutoValue users’ guide" w/ url: http://goo.gl/Ter394

However, that url points to a doc saying:

" Moved to https://github.com/google/auto/tree/master/value
I'm sorry for the inconvenience! "

It will be great the presentation is updated with the correct url.

Hamcrest's hasPropertyWithValue doesn't work with AutoValue

AutoValue generates package-private classes, which
org.hamcrest.beans.HasPropertyWithValue can't (won't?) access.

Hamcrest throws this error:

Class org.hamcrest.beans.HasPropertyWithValue$1 can not access a member of class AutoValue_XXXX with modifiers "public"

I understand that's by design, but decided to file a bug in case someone searches for it.

"Shade" the processors to internalize their dependencies to avoid interactions with other processors that use related libraries.

This involves moving all the dependency version information into the processors proper, plus hooking up either a maven-shade-plugin or maven-jarjar-plugin.

Document AutoFactory#className and eagerly enforce the contract

className property of the AutoFactory should either accept the fully qualified name (preferably, as it name implies) or the javadoc should clearly mention that it is actually the simple classname (current situation which actually limits functionality so not really desired(?)).

AutoBuilder?

Hi,

is there something like an AutoBuilder planned? Looking at the following class

@AutoValue
public abstract class MyValue {
    public abstract String getFirst();
    public abstract String getSecond();
}

it would be great if I could do the following

MyValue value = MyValue.builder()
    .withFirst("hello")
    .withSecond("world")
.build();

Or are there compelling reasons against? I know of auto factories but they serve another purpose.

-- ooxi

AutoValue breaks on recursive generic bounds

  interface Mergeable<M extends Mergeable<M>> {
    M merge(M other);
  }

  @AutoValue
  static abstract class Delta<M extends Mergeable<M>> {
    abstract M meta();
  }

...results in a stack overflow in TypeSimplifier.

Document the order of AutoValue fields, taken from superclasses and interfaces

public class AutoValueTest {

    public static void main(String[] args) {
        System.out.println(
                new AutoValue_AutoValueTest_Sub(1.0f, 'c', 2L, 1, "s", null));
    }

    static interface Interface1 {
        float getFloat();
        Object getObject();
    }

    static interface Interface2 {
        float getFloat();
        char getChar();
    }

    static interface Interface3 {
        long getLong();
    }

    static abstract class Super implements Interface2, Interface3 {
        abstract int getInt();
    }

    @AutoValue
    static abstract class Sub extends Super implements Interface1, Interface2 {
        abstract String getString();
        public abstract Object getObject();
    }
}

Please, document the order of AutoValue_AutoValueTest_Sub constructor arguments.

AutoFactory: generate inner class, not standalone

Not sure if it's possible, but it would be great if generated factories would be called

Bar.Factory instead of BarFactory.

If we're lucky, this'll allow the ctor that the factory calls to be private, as well as potentially making factory usage less verbose:

import com.bla.bla.Bar;
Bar b = new Bar.Factory().create();

instead of

import com.bla.bla.Bar;
import com.bla.bla.BarFactory;
Bar b = new BarFactory().create();

AutoFactory: allow annotating factories

My manually-written factories sometimes have annotations to allow some compile-time validating.
Would be awesome if I could write

@autofactory(annotate = BlaBlaAnnotation)
public Foo();

to have this generated:

@BlaBlaAnnotation
class FooFactory {}

AutoValue with Jackson deserialization

Hi,

I was using AutoValue with Jackson. It works for serialization if I add @JsonProperty on all abstract methods. However, for deserialization, it will throw error like:

Can not construct instance of com.example.AccountDto, problem: abstract types either need to be mapped to concrete types, have custom deserializer, or be instantiated with additional type information

I can write custom Jackson deserializer to fix it, but it's a lot of work if I need to write custom deserializer for each value object that I need. Is there a better way to handle this issue?

Thank you!