*CDI uses proxy objects to enable many of the CDI features, by hooking into message-passing from client to service beans. Under the hood, a proxy is an instance of an automatically generated class that extends the proxied bean type, so communicating through a proxy occurs transparently, as it has the same polymorphic type as the actual bean. Whether proxying is enabled or not is defined in the scope: CDI scopes are either normal scopes, which can be proxied, or pseudoscopes, which use direct references to injected beans.
The proxying mechanism creates some requirements for injecting objects in normal scope:
The objects may not be primitive types or arrays
The bean class must not be final
The bean class must not have final methods
Beans annotated with @UIScoped or @ViewScoped use a pseudoscope, and are therefore injected with direct references to the bean instances, while @NormalUIScoped and @NormalViewScoped beans will use a proxy for communicating with the beans.
When using proxies, be aware that it is not guaranteed that the hashCode() or equals() will match when comparing a proxy to its underlying instance. It is imperative to be aware of this when, for example, adding proxies to a Collection.
You should avoid using normal scopes with Vaadin components, as proxies may not work correctly within the Vaadin framework. If Vaadin CDI plugin detects such use, it displays a warning such as the following:
*
Hmm, I have to re-check, I don’t recall seeing that warning. OTOH, a presenter and a view cross-injecting each other without proxies will probably result in a cyclic dependency anyway(?)