Skip to content

Re Implements MultiMap #143

Description

@xsalefter

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions