Age | Commit message (Collapse) | Author |
|
am: 080ef5fd67 am: 77f6e08c51
am: 411312e790
Change-Id: Ica6ea71648acaaded0d0fb89683a6ce63e3a8f52
|
|
am: 080ef5fd67
am: 77f6e08c51
Change-Id: Id9de2d283bacb0982614efd29cd733b8bbf91271
|
|
am: 080ef5fd67
Change-Id: I0c23243c1ec95b001fde81b09527fd9808a51b3c
|
|
am: 0afca749f4
Change-Id: I559c4b161100efac08a60c6677147ebe578ce0d2
|
|
BUILD_HOST_STATIC_DALVIK_JAVA_LIBRARY must be used for libraries
that will be linked with LOCAL_STATIC_JAVA_LIBRARIES.
Test: m -j java
Change-Id: Ibf03dd9255882d472b6172602e74e8d9de981b1c
|
|
am: fd4da2840b
Change-Id: I9dca646f0943511e5b280fbf4c5ca60f3534b277
|
|
am: dac8e85864
Change-Id: Icb34fae18a0864848384fbb7266d01ad49984573
|
|
am: b6e6f3ada8
Change-Id: I9e3148e8b44d2743b8b627b97900b3be78914a31
|
|
am: 788548b2d6
Change-Id: Id47886afc34e47ece769cc8707add1f731363433
|
|
Bug: 30188076
Test: make checkbuild
Change-Id: Ic8d56444a37c7425f72c4c55b3b936583b46ee80
|
|
am: 6455114
* commit '6455114c53029b9e0511dfbb6280c10c461ccc6c':
build: Add device-side support for the AOSP.
Change-Id: Id58eea3d9f10df481f82776478bfce74c5c15add
|
|
am: dd02cae
* commit 'dd02cae677404f96e0359e51d0a77ac91174a057':
build: Add device-side support for the AOSP.
Change-Id: If8b54fff67d32d308246081db6dfb74664031ef1
|
|
am: 61c5de6
* commit '61c5de62c488a0140ab6dd8a9ba7ec3ff9dcf95b':
build: Add device-side support for the AOSP.
Change-Id: I1b27bcda47b53f63c6e2968b976d96074dc171b4
|
|
am: 3c28180
* commit '3c281807bfef61b077cb2e010890c11be31feb6b':
build: Add device-side support for the AOSP.
Change-Id: Ie6f6842dd4d24d0bd8f312fc7d5f5ab12a4e3a3f
|
|
Bug: 27521545
Change-Id: Ic254894f7dc838e0529b6cd648838b51fea84d0d
(cherry picked from commit 83b7ddb6a7b4db66d57c35ceb51fdbbb8a922aff)
|
|
am: af3b325
* commit 'af3b325e3a3a431d50aac8548e7e03868724420d':
build: Add device-side support for the AOSP.
Change-Id: I03607cb6da62c9566828dff6a5456fa62eb00daa
|
|
am: 83b7ddb
* commit '83b7ddb6a7b4db66d57c35ceb51fdbbb8a922aff':
build: Add device-side support for the AOSP.
Change-Id: If825a74820cd3b5e938cb4effe8dfff5e260b0f0
|
|
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
|