Open eclipse-viatra-bot opened 6 months ago
eclipse-viatra-bot
commented
6 months ago By Gabor Bergmann on Jul 04, 2018 07:16
We do have IMultiLookup, but its usage has not yet been introduced everywhere. Probably the long-term solution would be to increase usage of this already existing facility.
eclipse-viatra-bot
commented
6 months ago By Zoltan Ujhelyi on Jul 04, 2018 07:20
Fair point, the first candidate would be the valueToFeatureMap field in EMFBaseIndexInstanceStore... :)
eclipse-viatra-bot
commented
6 months ago By Zoltan Ujhelyi on Dec 06, 2018 16:46
Another candidate would be FixedPriorityConflictResolver#priorityBuckets, see bug 542490 for direct motivation.
eclipse-viatra-bot
commented
6 months ago By Zoltan Ujhelyi on May 27, 2019 07:49
Bugzilla cleanup.
eclipse-viatra-bot
commented
6 months ago By Zoltan Ujhelyi on Nov 20, 2019 05:51
Postponing issues to the next release.
eclipse-viatra-bot
commented
6 months ago By Zoltan Ujhelyi on May 18, 2020 13:04
Postponing issues that will not be solved for version 2.5.
eclipse-viatra-bot
commented
6 months ago By Zoltan Ujhelyi on Nov 23, 2020 08:30
Mass postponing of issues to the 2.6 timeframe.
| --- | --- | | Bugzilla Link | 536680 | | Status | NEW | | Importance | P3 normal | | Reported | Jul 04, 2018 07:11 EDT | | Modified | Nov 23, 2020 08:30 EDT | | Version | 2.1.0 | | Reporter | Zoltan Ujhelyi |
Description
When we have reduced the usage of Guava, we have lost the ability to reuse the Multimap interface. We have replaced those usages with Map<Key, Collection> but that behaves differently in case of missing keys: Guava Multimaps ensure that get never returns null; while the same is not true for the replacement.
I propose to have a way to have a generic null-safe multimap implementation to avoid issues like bug 536647 (and that was not the first) in the future.