History log of /external/guice/core/test/com/google/inject/spi/ProviderMethodsTest.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
9867f9c2142355ae958f9eeb8fb96811082c8812 02-Feb-2015 sameb <sameb@google.com> Implement my old patch for issue #366, with some tweaks. This does the
following:
* Fixes @Provides injection so that parameters are checked for nullability.
By default this will error. The flag is named:
guice_check_nullable_provides_params and can be set to ERROR, WARNING or IGNORE.
* Adds InjectionPoint.forMethod to build an InjectionPoint off an arbitrary
method.
* Adds Binder.getProvider(Dependency) to a get a Provider for a given
dependency (with all its nullability & injection points maintained).
* Update ProviderLookup to accept a Dependency in addition to a Key.

This is in preparation for two things:
1) Allowing multibindings/mapbindings/optionalbindings to be specified as
annotations on methods in a module.
2) Adding a dagger compatibility module.
... the general idea will be that I'll also add a hook into
ProvidesMethodModule somehow to look at arbitrary other annotations and let
folks process them specially.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=85353820
/external/guice/core/test/com/google/inject/spi/ProviderMethodsTest.java
76be88e8140f77a25824f5deb67bb13b8e5dabc6 01-Jul-2014 Sam Berlin <sameb@google.com> Detect overrides of @Provides method and add an error for each one.

Overriding an @Provides method is fairly rare and can be very confusing (e.g. a covariant override). This will not be backwards compatible for open source users.

See: https://groups.google.com/d/msg/google-guice/bRo5SvmzpdI/_uIfF3yUy9gJ for the public discussion
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=70120926
/external/guice/core/test/com/google/inject/spi/ProviderMethodsTest.java
c00df28be8bfa45b2bdc8b4d3c101c20a9cbdc12 01-Jul-2014 Sam Berlin <sameb@google.com> Automated code cleanups by internal tool.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=69390543
/external/guice/core/test/com/google/inject/spi/ProviderMethodsTest.java
53a5936f55056dc695c35e6e16233c5b49780ded 24-May-2014 Sam Berlin <sameb@google.com> Ignore synthetic bridge methods during provider method lookup.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=67854418
/external/guice/core/test/com/google/inject/spi/ProviderMethodsTest.java
409e0f578b620c38f6c8626dee78783219d2956e 10-May-2014 Sam Berlin <sameb@google.com> Try to use cglibs FastClass to invoke @Provides methods, it's faster!

Here is a caliper benchmark to demonstrate the difference.
https://caliper.googleplex.com/runs/2d349fec-2742-45e1-b6e5-16997c522387#r:scenario.benchmarkSpec.methodName,scenario.benchmarkSpec.parameters.strategy

This should save about 200-300 ns per method invocation and about 224 bytes (over 4 objects) of allocations for each invocation.

The cost of this (of course) is greater permgen usage and potentially slower startup/injector creation due to the class generation.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=66364901
/external/guice/core/test/com/google/inject/spi/ProviderMethodsTest.java
29ce12be89584ca1ad671408ecbe0f6c343f9382 10-Mar-2014 Sam Berlin <sameb@google.com> Add an SPI for @Provides methods (using the extensions SPI) so that users can
do more analysis (with the enclosing instance, method, etc..).

Notably, this can let users write analysis that looks for @Provides methods
declared with @Nullable, and compare against injection points w/o @Nullable,
failing if so.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=62834918
/external/guice/core/test/com/google/inject/spi/ProviderMethodsTest.java
8ad60eb50961e000c89099bb767489cf551d995b 10-Mar-2014 Sam Berlin <sameb@google.com> Change LinkedBindingBuilder.toProvider(Provider) to accept a jsr330 provider,
in addition to the Guice Provider. This is an incompatible change for people who extend LinkedBindingBuilder, but not for people who use it.

This will allow people to switch to JSR330 types more easily.

LinkedBindingBuilder needs both toProvider(Provider) and toProvider(javax.inject.Provider) because precompiled jars (e.g, stuff in third_party, maven, etc..) that used toProvider(Provider) would otherwise throw a NoSuchMethodError.

I left the getProviderInstance method on ProviderInstanceBinding, otherwise
that would require anyone using the SPI method to change their code to accept
the weaker type.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=61966924
/external/guice/core/test/com/google/inject/spi/ProviderMethodsTest.java
2e39ef748a1c4e4dcab506ccfcdb14ca6e01c9c6 05-Oct-2013 Christian Edward Gruber <cgruber@google.com> Print out the modules that led to a binding during error reporting, but
only if there's >1 module (otherwise it's just noise). The format is
Some normal messaging about the fact that something terrible happened
at <the normal source> (via modules: A -> B -> C)

So, for example, exposing something that isn't bound would show up as:
1) Could not expose() Foo, it must be explicitly bound.
at FooExposerModule.configure(FooExposerModule.java:211) (via modules: ParentModule -> FooExposerModule)

.. and a duplicate binding would show up as:
A binding to DuplicatedThing was already configured at ModuleA.configure(ModuleA.java:36) (via modules: ParentModule -> FooModule -> ModuleA)
at ModuleA.configure(ModuleA.java:36) (via modules: ParentModule -> BarModule -> ModuleA)

All the tests passed as-is (because this is just new information), so I made a bunch of tests stricter to explicitly look for this new information.

I also cleaned up some other errors regarding scopes & some other stuff.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=53039251
/external/guice/core/test/com/google/inject/spi/ProviderMethodsTest.java
b7a02b02d81c830d148355c90bc309bcd66fb592 08-Jul-2011 sberlin <sberlin@d779f126-a31b-0410-b53b-1d3aecad763e> * Remove unused imports
* Sort imports
* Convert tabs to spaces
* Fix the ant no_aop build


Revision created by MOE tool push_codebase.
MOE_MIGRATION=2532


git-svn-id: https://google-guice.googlecode.com/svn/trunk@1572 d779f126-a31b-0410-b53b-1d3aecad763e
/external/guice/core/test/com/google/inject/spi/ProviderMethodsTest.java
d9c913acca55023ef5d76a32c3d4a51ee6b420cb 26-Jun-2011 sberlin <sberlin@d779f126-a31b-0410-b53b-1d3aecad763e> switch Guice from manually repackaging Guava to depending on Guava. it's still jarjar'd right now, which is causing a ~400k increase in guice-snapshot.jar. next step is to switch to ProGuard to remove the unnecessary code and cut it back down (even further?!). this will let people build from Guice source and depend directly on Guava code without having to worry about hiding internal/util.

git-svn-id: https://google-guice.googlecode.com/svn/trunk@1558 d779f126-a31b-0410-b53b-1d3aecad763e
/external/guice/core/test/com/google/inject/spi/ProviderMethodsTest.java
74d714c1e72bb60706ed9df4d1982971c88c10aa 21-Oct-2010 mcculls <mcculls@d779f126-a31b-0410-b53b-1d3aecad763e> Issue 552: (step 1) move core code to its own subdirectory

git-svn-id: https://google-guice.googlecode.com/svn/trunk@1300 d779f126-a31b-0410-b53b-1d3aecad763e
/external/guice/core/test/com/google/inject/spi/ProviderMethodsTest.java