After some discussion with Don, I'm going to leave the current JIRA behaviour as-is and let them change SAL to understand that some containers do strange things. The current interface is underspecified and says nothing about values needing to be unique or distinct and nothing about the relationship between keys and values. (If I return a map with multiple things in it, how does the application know which one to use? How does it know which keys are valid and what they are supposed to map to?) If we could redefine the interface in SAL we might do things differently but now it is a legacy API that we need to keep for backwards compatibility.
The problem is that when you ask PICO for everything that implements "PluginAccessor" it goes through its complete map of registered keys and values, seeing which values are isAssignable. The values for the keys "PluginManager", "PluginController", and "PluginAccessor" all satisfy that, which is why we end up with a map with three things in it.
If we really wanted to change this Jed suggested something like: create a child PICO container and have that manage the lifecycle of the JiraPluginManager. Then, in the parent container, register proxies that only implement a single interface (i.e. only PluginAccessor).
That sounds to me like an unnecessary complication just to make SAL happy for one class.
Suggestion
After some discussion with Don, I'm going to leave the current JIRA behaviour as-is and let them change SAL to understand that some containers do strange things. The current interface is underspecified and says nothing about values needing to be unique or distinct and nothing about the relationship between keys and values. (If I return a map with multiple things in it, how does the application know which one to use? How does it know which keys are valid and what they are supposed to map to?) If we could redefine the interface in SAL we might do things differently but now it is a legacy API that we need to keep for backwards compatibility.
The problem is that when you ask PICO for everything that implements "PluginAccessor" it goes through its complete map of registered keys and values, seeing which values are isAssignable. The values for the keys "PluginManager", "PluginController", and "PluginAccessor" all satisfy that, which is why we end up with a map with three things in it.
If we really wanted to change this Jed suggested something like: create a child PICO container and have that manage the lifecycle of the JiraPluginManager. Then, in the parent container, register proxies that only implement a single interface (i.e. only PluginAccessor).
That sounds to me like an unnecessary complication just to make SAL happy for one class.