Relation to JSR 330

Toothpick fully implements the JSR 330.

The key features of this implementation are:

• usage javax.inject annotations. Toothpick adds a few more annotations such as @ProvidesSingleton, @Releasable;
• support of field injections, method injections, constructor injections;
• support of scopes, i.e. instance recycling (singleton). Toothpick also adds scope constraint checking;
• definition of custom scopes;
• qualified/named injections using annotation or string names
• thread safety, not only in places prescribed by the JSR 330.

Regarding JSR 330, Toothpick brings some new aspects by:

• defining a DAG of scopes, understood as a constraint checking system to prevent memory leaks.
• toothpick's injector is stateless, scope agnostic. Generated code is scope aware.
• toothpick internally delegates everything to providers. We consider that providers are the key indirection layer of dependency injection. Besides injection itself (i.e. field assignment, method and constructor calls), providing the right injected value is the hard question in DI and providers are the answers in TP, providers that maybe scoped...or not !

In Toothpick 3, scopes are interpreted in a different way than most DI libraries relying on the JSR 330. In the JSR, scopes are not very clearly defined and there is a confusion between scoping a class or a binding and making it a singleton of this scope. Toothpick distinguishes the two to provide much more fine grained control over scope verification. You can annotate a class with a scope annotation without making it a singleton, and you can also make it a singleton if you want. You can even make it a releasable singleton. This difference in the interpretation of the JSR 330 is one of the main features of TP 3.