We are in the process of developing a CDI plugin for an existing Java framework. We want to be able to use proxies with our existing components, but the hashCode and equals -methods are giving us problems. Specifically, the way in which the framework has been implemented so far causes us to use the proxy and the underlying instance interchangeably. This causes problems especially when placing the proxy/underlying instance to a collection.

Many of the design decisions in the framework predate the need to support proxies. Our public API enforces the following pattern:

UI#addWindow(Window subwindow) which places the subwindow directly into a collection, and opens it. This is paired with Window#close() which closes the subwindow and removes it from the parent.

Things work fine until the Window is a proxy. The proxy is placed into a collection where the proxy's hashcode is used as the key. Then when we try to close the Window, the proxy is resolved prior to calling close() and we try to remove it from the collection using the contextual instance's hashcode.

Similar problems occur with most components, causing at best memory leaks and at worst non-functional components.

I understand the reasons why the client proxies behave as they currently do. The hashcode must be stable even if the contextual instance changes, same with equals.
What makes this so frustrating for us is that we know that in our case the contextual instance would not change during the lifetime of the proxy. While not delegating is perfectly logical in the general case, the reasons why are simply not relevant for our case. We've already got everything to work with OWB, we've managed to resolve the potential proxy / contextual instance equals-issue to our satisfaction. The only thing preventing us from fully supporting normal scopes with our components is the fact that we can't inform Weld that it should not enforce it's own implementation for equals and hashCode on client proxies. Could we please make this a configurable thing?

This ticket is very related to

I hope we can find some way to resolve this issue. Thank you for your time.
Sincerely,
Juuso Valli