killbill/killbill-commons

Re Implements MultiMap

xsalefter opened this issue · 0 comments

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 use Map<LifecycleLevel, SortedSet<LifecycleHandler<? extends KillbillService>>> handlersByLevel;

  • RequestOptions in killbill-client-java : Not mandatory (like DefaultLifeCycle above), but more to usability problem. Currently, MultiValueMap is useless if user/client code of killbill-client-java want to use MultiValueMap.

    (as part of killbill-client-java no-guava refactoring, I'm planning to use Map<String, Collection<String>> to queryParams and queryParamsForFollow. This make MultiValueMap useless because it based on Map<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.