_Original issue created by nimrod.priell on 2009-03-12 at 08:19 AM_
I think this is one very strong class in the API and you made it package
viewable only. So I can't for example build a BiMap backed by my own map
implementations or some standard java impl. like LinkedHashMap for
insertion-order iteration.
_Original comment posted by kevinb9n on 2009-03-12 at 06:39 PM_
It's always been a future possibility, but designing and documentation for
inheritance is a painful, very time-consuming activity and is not a priority for 1.0.
Bear in mind that ImmutableBiMap is insertion-ordered, and that insertion-ordered
_mutable_ bimaps can be kind of confusing because their key set and value set don't
iterate in the corresponding order.
_Original comment posted by jared.l.levy on 2009-03-12 at 06:43 PM_
Instead of making StandardBiMap public, we could instead create a BiMaps.newBiMap()
method that takes backing maps as input parameters. That approach avoids problems
that arise when collection classes are publicly extendable.
We currently don't have that method because, until now, nobody has asked for it.
_Original comment posted by kevinb9n on 2009-03-12 at 06:46 PM_
Actually, we used to have it, for a long time, internally, and then we noticed that
of the few people who used it, none of them were actually getting the benefit from it
they thought they were. We decided after giving it a chance that this was not very
useful, and we got rid of it.
_Original comment posted by kevinb9n on 2009-09-12 at 02:14 AM_
_(No comment entered for this change.)_
Labels: post-1.0
_Original comment posted by kevinb9n on 2009-09-12 at 02:15 AM_
_Issue #235 has been merged into this issue._
_Original comment posted by kevinb9n on 2009-09-17 at 05:45 PM_
_(No comment entered for this change.)_
Labels: -post-1.0, Milestone-Post1.0
_Original comment posted by kevinb9n on 2009-09-17 at 05:57 PM_
_(No comment entered for this change.)_
Labels: Type-Enhancement
_Original comment posted by kevinb9n on 2009-10-30 at 04:00 PM_
_Issue #283 has been merged into this issue._
_Original comment posted by [email protected] on 2010-07-30 at 03:53 AM_
_(No comment entered for this change.)_
Labels: -Milestone-Post1.0
_Original comment posted by [email protected] on 2011-01-26 at 09:50 PM_
_(No comment entered for this change.)_
Status: Accepted
_Original comment posted by [email protected] on 2011-07-13 at 06:18 PM_
_(No comment entered for this change.)_
Status: Triaged
_Original comment posted by [email protected] on 2011-12-10 at 03:36 PM_
_(No comment entered for this change.)_
Labels: Package-Collect
_Original comment posted by [email protected] on 2012-02-16 at 07:17 PM_
_(No comment entered for this change.)_
Status: Acknowledged
_Original comment posted by [email protected] on 2012-05-30 at 07:43 PM_
_(No comment entered for this change.)_
Labels: -Type-Enhancement, Type-Addition
_Original comment posted by [email protected] on 2012-06-22 at 06:16 PM_
_(No comment entered for this change.)_
Status: Research
_Original comment posted by [email protected] on 2012-11-07 at 08:21 PM_
_Issue #1195 has been merged into this issue._
_Original comment posted by amend6 on 2013-01-10 at 02:02 PM_
Related to this I want to extend the RegularImmutableBiMap,
but there is no public class access.
_Original comment posted by [email protected] on 2013-01-10 at 05:01 PM_
The immutable collections can definitely not be extensible. That's part of Effective Java item 15 -- immutable classes cannot be extended.
We're considering making HashBiMap insertion ordered by default, but there still may be value in having a BiMapBuilder (similar to MultimapBuilder).
We're kicking around a design like this
How much interest is there in this?
So each direction might maintain its own separate iteration order, but if one side is plain "hash" then it should probably just reuse the iteration order of its inverse, since anything's better than arbitrary order.
Nobody needed this since 2015?
Most helpful comment
We're kicking around a design like this
How much interest is there in this?
So each direction might maintain its own separate iteration order, but if one side is plain "hash" then it should probably just reuse the iteration order of its inverse, since anything's better than arbitrary order.