What are the scopes of GIN bindings?

I wonder what scopes folowing two bindings have:

bind(PermissionManager.class).in(Singleton.class);

and

bind(PermissionManager.class);

I have read the JavaDocs, they are as following. For Singleton:

/**
* Apply this to implementation classes when you want only one instance
* (per {@link Injector}) to be reused for all injections for that binding.
*
* @author crazybob@google.com (Bob Lee)
*/

For no scope:

/**
* No scope; the same as not applying any scope at all.  Each time the
* Injector obtains an instance of an object with "no scope", it injects this
* instance then immediately forgets it.  When the next request for the same
* binding arrives it will need to obtain the instance over again.
*
* <p>This exists only in case a class has been annotated with a scope
* annotation such as {@link Singleton @Singleton}, and you need to override
* this to "no scope" in your binding.
*
* @since 2.0
*/

What does this mean in practical terms? Are singletons per client or per JVM? For no scope, is every instance different?

Solution

In practical terms for Gin, the Singleton scope makes the most sense when considered per client instance, or even more accurately, per Ginjector instance. If you make the mistake of making two Ginjectors by GWT.createing an instance twice, you likely will have one 'singleton' per instance, since each Ginjector can only keep track of the instances it manages.

So each time your application loads, it will have its own singleton. If the user opens the same application twice in two different tabs, each will have its own singleton. You could consider each tab to be its own JVM, as it will have its own copy of all of the classes, and won't be able communicate, or call methods* on the other window.

For no scope, yes, by default each instance is different. When a type is @Injected, it will be a new instance there, but if you @Inject a Provider for a field, every time you call get() you can get a fresh instance. This can be helpful to get several newly injected instances easily.

Singletons make sense to use in two main cases

When the instance holds shared state that needs to be common across many injections - the most common case.
When the instance is expensive to create - on the server this is often done as a pool, so no more than X objects are created, but the expensive objects on the client tend to be views, with lots of widgets, and generally more than one is not required.

* It is possible to call methods on another window, but you need to use the browser's capabilities for this, by posting a message, not by just passing an object back and forth.