History log of /external/guice/core/src/com/google/inject/internal/ConstructorBindingImpl.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
5e6c93348c4250012801b6e41753789d760f06e4 20-Apr-2015 timofeyb <timofeyb@google.com> Implement more granular locks for a Singleton scope in Guice.

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
/external/guice/core/src/com/google/inject/internal/ConstructorBindingImpl.java
c34e0185fcf508a890c6cd13bdafeb505c3e9e8a 06-Aug-2014 Sam Berlin <sameb@google.com> Implement binding deduplication for multibinder & mapbinder in a different way.
Instead of relying on Guice binding deduplication (and hacking up RealElement
to break the annotation contract to do so, causing weirdness in WeakKeySet &
forcing us to care about "rehashing keys"), we instead deduplicate within
Multibinder. The downside of this is that toInstance or toProvider(instance)
bindings that are deduplicated will remain in the object graph but effectively
be unreachable. However, that's a downside I'm willing to live with to remove
this hack.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=72570932
/external/guice/core/src/com/google/inject/internal/ConstructorBindingImpl.java
96e81ba55441fd11c189d903ee2bd1806a23bd70 18-Sep-2013 Christian Edward Gruber <cgruber@google.com> An alternative way to support ShareableModule, Modules.override and Multibinder: use annotations that compare equal iff the binding strategy matches, so Guice will dedupe for us.

This CL includes a noteworthy adaptation of an earlier attempt which caused timeouts in some client tests, forcing a rollback ([]). Because Key caches its hashCode, we were inadvertently inserting every binding for a given multibound set into the same hashmap bucket, causing at best O(n^2) behaviour (and possibly worse, depending on how HashMap is implemented). To fix this, this CL adds changes to core Guice to recompute the Key's hashCode at injector construction time. (In fact, at the end of every Elements.getElements call, so any SPI-based code gets the same benefits.)
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=51233981
/external/guice/core/src/com/google/inject/internal/ConstructorBindingImpl.java
c756777526309dc6c9ff2b5df80a8f811d390c09 01-Jun-2012 Sam Berlin <sameb@google.com> Add Binder.requireAtInjectOnConstructors, to force Guice to require @Inject annotations on constructors.

Revision created by MOE tool push_codebase.
MOE_MIGRATION=4906
/external/guice/core/src/com/google/inject/internal/ConstructorBindingImpl.java
d51292d5a4a788b1275eb9ad55cf612e68640bbf 27-Feb-2012 Sam Berlin <sameb@google.com> Change ProvisionListener to expose Binding instead of Key, and change bindListener to use a Matcher for Binding instead of Key. This is a backwards incompatible change, but we haven't released yet, so it's worth doing.

Revision created by MOE tool push_codebase.
MOE_MIGRATION=4269
/external/guice/core/src/com/google/inject/internal/ConstructorBindingImpl.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/src/com/google/inject/internal/ConstructorBindingImpl.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/src/com/google/inject/internal/ConstructorBindingImpl.java
132a5db7c643b8f367eb5f09024cf13ea37c9831 05-Jun-2011 sberlin <sberlin@d779f126-a31b-0410-b53b-1d3aecad763e> issue 78 - provision interception. this only lets you listen to provisions (both before & after provisioning occurs), it does not let you change the return value of the provision.

git-svn-id: https://google-guice.googlecode.com/svn/trunk@1551 d779f126-a31b-0410-b53b-1d3aecad763e
/external/guice/core/src/com/google/inject/internal/ConstructorBindingImpl.java
d5737a60194ed44bfd8ae7948f9ca7806785d2dd 02-May-2011 sberlin <sberlin@d779f126-a31b-0410-b53b-1d3aecad763e> fix @ProvidedBy circular dependencies.

git-svn-id: https://google-guice.googlecode.com/svn/trunk@1546 d779f126-a31b-0410-b53b-1d3aecad763e
/external/guice/core/src/com/google/inject/internal/ConstructorBindingImpl.java
fc46e1a98e70d22e5674a4aa42ede2fdede6a25a 15-Dec-2010 limpbizkit@gmail.com <limpbizkit@gmail.com@d779f126-a31b-0410-b53b-1d3aecad763e> Fix warnings in core.

git-svn-id: https://google-guice.googlecode.com/svn/trunk@1460 d779f126-a31b-0410-b53b-1d3aecad763e
/external/guice/core/src/com/google/inject/internal/ConstructorBindingImpl.java
8b64d455b982d5841480a0247c15d68de0759c91 13-Dec-2010 sberlin <sberlin@d779f126-a31b-0410-b53b-1d3aecad763e> Remove InjectorBuilder in favor of methods in Binder.

git-svn-id: https://google-guice.googlecode.com/svn/trunk@1457 d779f126-a31b-0410-b53b-1d3aecad763e
/external/guice/core/src/com/google/inject/internal/ConstructorBindingImpl.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/src/com/google/inject/internal/ConstructorBindingImpl.java