You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 simpleMap
with ability to store multiple values. Thus we have MultiValueMap.The main problem with
MultiValueMap
is that it usesList
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.The text was updated successfully, but these errors were encountered: