| Age | Commit message (Collapse) | Author |
|---|
|
Bug: 27521545
Change-Id: Ic254894f7dc838e0529b6cd648838b51fea84d0d
|
|
Bug: 27552463
Change-Id: If058b2de991c4813d49a5d844b8610405fb3bc5f
|
|
Builds the no_aop variant only since Android doesn't support bytecode
weaving.
Bug: 27552463
Change-Id: I71b4f3b26b9307b36444cecc75d67de03be9cb23
|
|
Bug: 27552463
Change-Id: I71cff480c9b5fb813f3209cd6186e96b124f94ca
|
|
Initial downstream of guice code (tag 4.0)
from https://github.com/google/guice/
Bug: 27552463
Change-Id: Ia72763ed396d2f3ac3bc2bc66fb3e383818e1c82
|
|
|
|
|
|
Merge internal changes.
|
|
extensions' package-info.java files.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=92005346
|
|
google/moe_writing_branch_from_156c8cc762fab971efb727c7ab107fa243be2fc9
Merge internal changes
|
|
dagger-adapter. Dagger 2 is now released, so this is not necessary.
Left the TODO in there, because the pom inheritance hierarchy needs to be brought up to something more current (e.g. sonatype's OSS parent pom, etc.)
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=91730888
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=91720693
|
|
Align dagger-adapter name and add it to the Bill-Of-Materials pom.xml
|
|
|
|
Add missing @since tags for classes
|
|
|
|
google/moe_writing_branch_from_156c8cc762fab971efb727c7ab107fa243be2fc9
Merge internal changes
|
|
api jar for the ant build)
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=91679331
|
|
Now when you can create two independent singletons using
the same injector in different threads.
This make it easy to create scopes creating singletons using
thread pools with all the concurrency being done by Guice.
As a nice side effect Singleton scope is no longer treated
specially in Guice codebase.
The obvious problem to solve is potential deadlocks:
A requires B, B requires C, C requires A where all are
singletons and all are created simultaneously.
It's impossible to detect this deadlock using information
within one thread, so we have to have a shared storage.
An idea is to have a map of creators' locks and a map
of which threads are waiting for other singletons to be created.
Using this information circular dependencies are trivially
discovered within O(N) where N is a number of concurrent threads.
Important to not that no other deadlock scenarios within
Guice code is introduced as Guice does not expose any
other scopes that can span several threads.
Now it would be possible for
client code to deadlock on itself with two lazy singletons
calling each other's providers during creation.
This is deemed as a non-issue as it is up to the client
to write a thread-safe code.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=91610630
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=89998087
|
|
Improve performance of internal DependencyStack collection
|
|
|
|
Merge internal changes
|
|
retain references to their parent classes. Still some more work to do in
WeakKeySet to let it clean up more frequently, but this should help for now.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=89328452
|
|
binders created from skipSources or withSource.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=89146131
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=87524840
|
|
|
|
|
|
google/moe_writing_branch_from_b605a34702d8d8112983aca891e3e2b6987ec45e
Merge internal changes
|
|
default methods for subclasses when they override generic methods with the more
specific type.
We use a two-tiered approach to fixing: (1) try to use MethodHandles + unreflectSpecial, which lets us call default method implementations directly, and if that doesn't work then (2) try to map default methods to compatible method signatures that could be the overrides of the method. (1) may not always work because we're using a private API [new Lookup(clazz, int)], but we need to do that in order to non-public classes. (2) may not always work because it's possible to have more than one compatible method signature.
In the unlikely case that both (1) & (2) fail, we give an error message.
Also: we must validate the default method's return type for visibility vs the factory type's visibility too.
This ends up with two possible differences caused by java8:
a) If the Lookup cxtor can't be used (different JDK, version skew, etc..) and there's more than one compatible method signature: we fail.
b) If the default method's return type isn't public but the factory is public: we fail.
For reference, javac8 generates a default method in the following scenario:
interface Parent<I extends CharSequence, O extends Number> {
O create(I input);
}
interface Child<String, Integer> {
Integer create(String input);
}
Child has a generated default method of:
Number create(CharSequence input);
... so, for example, failure could be newly triggered if 'Number' was package-private but Child was public, or if the reflection APIs didn't work and Child also had a 'Integer create(StringBuilder input);' method.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=87097207
|
|
rely on snapshot versions of things while in development.
This should change nothing about release-time as snapshot dependencies are not kosher for release.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=86827570
|
|
the parent (which should happen automatically), and use ${project.version} instead of hard-coding the version... like the other extensions.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=86826607
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=86803793
|
|
to annotate methods in a Module as elements that can contribute to a
Multibinder, MapBinder, or OptionalBinder.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=86801706
|
|
Instead of requiring each scanner to explicitly wrap the modules to-be-scanned,
we add a Binder.scanModulesForAnnotatedMethods method that takes a scanner,
and we scan every installed module.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=86751798
|
|
scanning did not ignore synthetic methods created by java8, leading to errors
when the factory interface extended from a superinterface that had generics.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=86628771
|
|
limitations) the use of Dagger modules in Guice.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=86617720
|
|
binding value is used.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=86504275
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=86029834
|
|
* use ArrayList.removeRange to pop the context, this allows us to elide range
checks.
* Don't eagerly allocate a Dependency object for the pushState(Key<?>,Object)
method, instead allocate one when constructing the DependencyChain.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=85562648
|
|
Merge moe changes
|
|
time w/o using Sets.newConcurrentHashSet.,
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=85377786
|
|
bindings and have those methods bound as Providers to specialized Keys.
This is the basis of what will be used to allow
Multibinder/MapBinder/OptionalBinder to have stuff like @SetProvides,
@MapProvides, @OptionalProvides and dagger interop support.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=85361820
|
|
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
|
|
types annotated with @Component. This allows one to provide Dagger Components with Guice Injectors.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=84836495
|
|
google/moe_writing_branch_from_1215316c7bae68bde9133f8fffa43c074c156633
Merge internal changes
|
|
No functional changes.
This will allow android apps to remove this method
via proguard in release mode.
For everything else, it should be almost a no-op, just one extra
indirection.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=83477074
|
|
<reportPlugins>.
This is apparently the preferred way to do this... the previous way shows errors in my IDE.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=83279354
|
|
binding.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=82465720
|
|
Use of '_' as a one-character identifier is deprecated in Java 9 [1]. In the
future it may be used as a keyword [2].
[1] https://bugs.openjdk.java.net/browse/JDK-8061549
[2] http://mail.openjdk.java.net/pipermail/lambda-dev/2013-July/010670.html
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=82146488
|
