profile
viewpoint
Gregory Kick gk5885 Google Chicago, IL

square/javapoet 8509

A Java API for generating .java source files.

gk5885/dagger-android-sample 238

A small, simple Android application that uses Dagger 2.

gk5885/dagger 4

A fast dependency injector for Android and Java.

gk5885/compile-testing 0

Testing tools for javac and annotatoin processors

gk5885/javapoet 0

A utility class which aids in generating Java source files.

gk5885/truth 0

Assertion/Proposition framework for Java unit tests (very alpha, and subject to change)

issue commentgoogle/guice

Move Logger binding out to LoggerModule, so users can bind their own Loggers

Running into this years later...

gissuebot

comment created time in 2 hours

issue commentgoogle/error-prone

RemoveUnusedImports is not working

Thanks @cushon this option worked for me. The only challenge is it is taking 2 passes

  1. In the first pass it removed my stale flag but imports are not imported.
  2. In the second pass it removed the unused imports.
cnarsimharaju

comment created time in 6 hours

issue closedgoogle/compile-testing

[feature request] support assert generate multi source file.

My annotation processor generate multi file for a annotationed class. If I use com.google.testing.compile.CompilationSubject#generatedSourceFile to test it. It said:

expected to generate file: /io/github/vipcxj/beanknife/tests/otherbeans/TestBean1Meta.java
in location              : SOURCE_OUTPUT
it generated:
  /SOURCE_OUTPUT/io/github/vipcxj/beanKnfie/tests/otherbeans/TestBean1Meta.java
  /SOURCE_OUTPUT/io/github/vipcxj/beanknife/tests/beans/TestBean1Meta.java
  /SOURCE_OUTPUT/io/github/vipcxj/beanKnfie/tests/otherbeans/ViewOfTestBean1.java
  /SOURCE_OUTPUT/io/github/vipcxj/beanknife/tests/beans/ViewOfTestBean1.java

	at io.github.vipcxj.beanknife.tests.ViewMetaProcessorTest.testViewMetaCase(ViewMetaProcessorTest.java:50)
	at io.github.vipcxj.beanknife.tests.ViewMetaProcessorTest.testBean1(ViewMetaProcessorTest.java:18)

And I can't find a method to support this use case.

closed time in a day

vipcxj

issue commentgoogle/compile-testing

[feature request] support assert generate multi source file.

My fault, beanKnfie is not equal to beanknife

vipcxj

comment created time in a day

issue openedgoogle/compile-testing

[feature request] support assert generate multi source file.

My annotation processor generate multi file for a annotationed class. If I use com.google.testing.compile.CompilationSubject#generatedSourceFile to test it. It said:

expected to generate file: /io/github/vipcxj/beanknife/tests/otherbeans/TestBean1Meta.java
in location              : SOURCE_OUTPUT
it generated:
  /SOURCE_OUTPUT/io/github/vipcxj/beanKnfie/tests/otherbeans/TestBean1Meta.java
  /SOURCE_OUTPUT/io/github/vipcxj/beanknife/tests/beans/TestBean1Meta.java
  /SOURCE_OUTPUT/io/github/vipcxj/beanKnfie/tests/otherbeans/ViewOfTestBean1.java
  /SOURCE_OUTPUT/io/github/vipcxj/beanknife/tests/beans/ViewOfTestBean1.java

	at io.github.vipcxj.beanknife.tests.ViewMetaProcessorTest.testViewMetaCase(ViewMetaProcessorTest.java:50)
	at io.github.vipcxj.beanknife.tests.ViewMetaProcessorTest.testBean1(ViewMetaProcessorTest.java:18)

And I can't find a method to support this use case.

created time in a day

push eventgoogle/error-prone

travis-ci

commit sha 272e6c690e772bce545241be5335ebb73a6d7c32

Latest docs on successful travis build 2817 auto-pushed to gh-pages

view details

push time in a day

delete branch google/error-prone

delete branch : test_343657126

delete time in a day

PR merged google/error-prone

Add a new bug checker to suggest using immutable collection when the collection is not mutated. cla: yes

Add a new bug checker to suggest using immutable collection when the collection is not mutated.

For now only tacking list and limiting to cases where mutable generic type is initialized with an immutable type.

+216 -0

0 comment

3 changed files

copybara-service[bot]

pr closed time in a day

push eventgoogle/error-prone

Ashish Kedia

commit sha aeafd79184b5ef0f8f8bd43980f2c21369449845

Add a new bug checker to suggest using immutable collection when the collection is not mutated. For now only tacking list and limiting to cases where mutable generic type is initialized with an immutable type. PiperOrigin-RevId: 344389214

view details

push time in a day

push eventgoogle/error-prone

Ashish Kedia

commit sha aeafd79184b5ef0f8f8bd43980f2c21369449845

Add a new bug checker to suggest using immutable collection when the collection is not mutated. For now only tacking list and limiting to cases where mutable generic type is initialized with an immutable type. PiperOrigin-RevId: 344389214

view details

push time in a day

create barnchgoogle/error-prone

branch : test_343657126

created branch time in a day

PR opened google/error-prone

Add a new bug checker to suggest using immutable collection when the collection is not mutated.

Add a new bug checker to suggest using immutable collection when the collection is not mutated.

For now only tacking list and limiting to cases where mutable generic type is initialized with an immutable type.

+216 -0

0 comment

3 changed files

pr created time in a day

issue commentgoogle/dagger

Compiler errors on java 11

Update

So, in a successful build we would have:

  • Processing round 1
    • ModuleProcessingStep: Defers processing ApplicationModule (It references DataBindingComponent, which is not yet valid).
  • Processing round 2
    • ModuleProcessingStep: Processes ApplicationModule (DataBindingComponent is now valid -- generated in round 1)

However, in Java 11 with kapt something is going wrong.

In processing round 2, DataBindingComponent is not a valid type (even though DataBindingComponent appears to be generated at some point). This means that calling TypeMirror#getKind() on the type returns an ERROR kind rather than a DECLARED kind. Weirdly though, SuperficialValidation thinks the DataBindingComponent type is valid because rather than checking its TypeMirror#getKind(), it uses a TypeVisitor, which is incorrectly visiting #visitDeclared() even though the corresponding type is an ErrorType. I can't find specific documentation, but this definitely seems like another related bug, since I would expect it to visit #visitError() in this case.

So what does this mean for Dagger?

From Dagger's perspective, we initially think DataBindingComponent is valid in round 2 because of the bug in the visitor, so we go ahead and process ApplicationModule. Then, we realize the provides method is actually returning an ErrorType and we fail with the error message in https://github.com/google/dagger/issues/2144#issuecomment-712436284.

Again, I don't think there's much Dagger can really do in this case. We're relying on the underlying type system, so if the type is invalid we can't really make it valid. This appears to be a deeper issue between kapt and java 11.

You can try filing a bug with kapt, although I'm not sure if the project is still actively fixing issues.

You might also want to file a bug with the androidx.databinding library. For example, this doesn't seem to be a in issue with other generated types like AutoValue. For example:

@Module
class ApplicationModule {
  @AutoValue static abstract class Foo {}

  // This type is valid with kapt and java 11
  @Provides
  AutoValue_ApplicationModule_Foo provideFooAutoValue() {
      return new AutoValue_ApplicationModule_Foo();
  }

  // This type is invalid with kapt and java 11
  @Provides
  DataBindingComponent provideDataBindingComponent() {
      return new DataBindingComponent() {...};
  }
}

Possible Workarounds

  1. Avoid binding DataBindingComponent directly, and either extend or wrap it Instead (see https://github.com/google/dagger/issues/2144#issuecomment-731908754). However, note that this is really just a hack that relies on the fact that Dagger currently doesn't inspect the super types directly, but the underlying bug is still there and may cause issues later if Dagger starts relying on it.
  2. Avoid using kapt in this situation -- it works with annotationProcessor
  3. Avoid using java 11 in this situation -- it works with java 8.
auras

comment created time in 2 days

issue openedgoogle/error-prone

CompileTimeConstant checks are bypassed depending on the reference type

Description of the problem / feature request:

CompileTimeConstant parameter validation is only done when the type which is directly annotated is referenced. Annotated interfaces are ignored when using a reference to a concrete implementation, and implementation annotations are ignored if a superclass or superinterface reference type is used.

Replace this line with your answer.

Feature requests: what underlying problem are you trying to solve with this feature?

Ideally there would be a mechanism to prevent CompileTimeConstant checks from being accidentally bypassed. I have implemented an errorprone check to require type hierarchies provide consistent annotations here: https://github.com/palantir/gradle-baseline/pull/1559 But there are other ways such validation could work.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

First case:

The check needs additional data at this point. I would recommend a second check which validates that all superclasses and superinterfaces are annotated matching the annotated implementation.

interface Iface {
  void accept(String value);
}

class Impl implements Iface {
  @Override
  public void accept(@CompileTimeConstant String value) {}
}

Then:

String dynamic = System.getProperty("java.specification.version");
Iface value0 = new Impl();
// Passes compilation as expected
value0.accept(dynamic);
Impl value1 = new Impl();
// Fails compilation
value1.accept(dynamic);

Second:

Implementing an interface with methods that contain constant parameters does not detect the constant annotation on the super-interface, allowing non-constant values and violating the contract. Likely a larger problem as the new var keyword becomes widespread.

This could be solved by expanding the compile-time-constant check to check super-interfaces, or by requiring subtypes add matching annotations (writing an automated fix is trivial). For what it's worth, I think it's helpful to add the annotation to all implementations because the code becomes more obvious to developers.

Given:

interface Iface {
  void accept(@CompileTimeConstant String value);
}

class Impl implements Iface {
  @Override
  public void accept(String value) {}
}

Then:

String dynamic = System.getProperty("java.specification.version");
Iface value0 = new Impl();
// Fails compilation as expected
value0.accept(dynamic);
Impl value1 = new Impl();
// Passes compilation
value1.accept(dynamic);

What version of Error Prone are you using?

2.4.0

Have you found anything relevant by searching the web?

no

created time in 2 days

issue commentgoogle/dagger

Hilt: Question, How to reuse a module and provide its bindings

For anyone coming to this issue, the solution provided by @bcorso works with a bit of adjustment, since the injection has not happened yet, you will get an NPE exception if you access the fooWidgetListdataSource so you can't have @Inject annotation on it like @Inject FooWidgetListdataSource fooWidgetListdataSource; instead, you can access your dependence with an entry point interface

override val widgetListRepository: WidgetListRepository by lazy {
        EntryPoints.get(this, ManageEntryPoint::class.java).manageRepository()
    }

    @EntryPoint
    @InstallIn(FragmentComponent::class)
    interface ManageEntryPoint {

        @Named(MANAGE)
        fun manageRepository(): WidgetListRepository
    }
MRezaNasirloo

comment created time in 2 days

delete branch google/error-prone

delete branch : test_343961699

delete time in 2 days

PR merged google/error-prone

Don't flag @Spy variables in UnnecessaryAnonymousClass cla: yes

Don't flag @Spy variables in UnnecessaryAnonymousClass

+30 -1

0 comment

2 changed files

copybara-service[bot]

pr closed time in 2 days

push eventgoogle/error-prone

Sumit Bhagwani

commit sha 757306bb2326e55e1456f8a7e5defdaf1eebfea0

Don't flag @Spy variables in UnnecessaryAnonymousClass PiperOrigin-RevId: 344259249

view details

push time in 2 days

push eventgoogle/error-prone

Sumit Bhagwani

commit sha 757306bb2326e55e1456f8a7e5defdaf1eebfea0

Don't flag @Spy variables in UnnecessaryAnonymousClass PiperOrigin-RevId: 344259249

view details

push time in 2 days

PR opened google/error-prone

Don't flag @Spy variables in UnnecessaryAnonymousClass

Don't flag @Spy variables in UnnecessaryAnonymousClass

+30 -1

0 comment

2 changed files

pr created time in 2 days

create barnchgoogle/error-prone

branch : test_343961699

created branch time in 2 days

delete branch google/dagger

delete branch : test_341659347

delete time in 2 days

push eventgoogle/dagger

Dagger Team

commit sha d67d2f6fc74a2c0129f198bba1cb36c98bdc4a97

[Hilt Documentation]: docs baseline 2 PiperOrigin-RevId: 344235493

view details

push time in 2 days

PR closed google/dagger

[Hilt Documentation]: docs baseline 2 cla: yes

[Hilt Documentation]: docs baseline 2

+0 -0

0 comment

0 changed file

copybara-service[bot]

pr closed time in 2 days

push eventgoogle/dagger

Dagger Team

commit sha d67d2f6fc74a2c0129f198bba1cb36c98bdc4a97

[Hilt Documentation]: docs baseline 2 PiperOrigin-RevId: 344235493

view details

push time in 2 days

PR opened google/dagger

[Hilt Documentation]: docs baseline 2

[Hilt Documentation]: docs baseline 2

+2 -2

0 comment

1 changed file

pr created time in 2 days

delete branch google/dagger

delete branch : test_344007461

delete time in 2 days

PR merged google/dagger

Internal change cla: yes

Internal change

+0 -0

0 comment

1 changed file

copybara-service[bot]

pr closed time in 2 days

push eventgoogle/dagger

Dagger Team

commit sha b7b842394fb9887eb52471477dad8028c4a5d922

Internal change PiperOrigin-RevId: 344215146

view details

push time in 2 days

push eventgoogle/dagger

Dagger Team

commit sha b7b842394fb9887eb52471477dad8028c4a5d922

Internal change PiperOrigin-RevId: 344215146

view details

push time in 2 days

more