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 useMap<LifecycleLevel, SortedSet<LifecycleHandler<? extends KillbillService>>> handlersByLevel;
-
RequestOptions
inkillbill-client-java
: Not mandatory (likeDefaultLifeCycle
above), but more to usability problem. Currently,MultiValueMap
is useless if user/client code ofkillbill-client-java
want to useMultiValueMap
.(as part of
killbill-client-java
no-guava refactoring, I'm planning to useMap<String, Collection<String>>
toqueryParams
andqueryParamsForFollow
. This makeMultiValueMap
useless 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.