-
-
Notifications
You must be signed in to change notification settings - Fork 64
Description
During Guava refactoring, we need replacement of Guava Multimap. Forking/copy every implementation is too much at that time because it contains a lot of import to other Guava classes. At initial work, what we really need is simple Map with ability to store multiple values. Thus we have MultiValueMap.
The main problem with MultiValueMap is that it uses List as value, thus we cant make use of other collection types as a value. So far, class(es) that need non-List as a value are:
-
org.killbill.billing.lifecycle.DefaultLifeCycle#handlersByLevel: Originally, use SortedSet as value. As currently no replacement, we need to useMap<LifecycleLevel, SortedSet<LifecycleHandler<? extends KillbillService>>> handlersByLevel; -
RequestOptionsinkillbill-client-java: Not mandatory (likeDefaultLifeCycleabove), but more to usability problem. Currently,MultiValueMapis useless if user/client code ofkillbill-client-javawant to useMultiValueMap.(as part of
killbill-client-javano-guava refactoring, I'm planning to useMap<String, Collection<String>>toqueryParamsandqueryParamsForFollow. This makeMultiValueMapuseless because it based onMap<String, List<String>>, so client code still need to deal with if-key-exist-add-else-put)
We can refactor MultiValueMap, but it is scattered in other modules. I think the real cost is not in refactor vs re-write, but in apply it.