commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [lang] ArrayUtils toMap asMap, [was Re: [collections] [PATCH] MapUtil]
Date Mon, 14 Oct 2002 22:07:18 GMT
[Opinions from [lang] committers desired, on inclusion of asMap into

I believe that this difficulty is the reason why asMap(Object[]) was never
included in the JDK, but toMap() was.

Here is my solution:
- Hashing - document the behaviour, stating that the Map will behave poorly
as its size grows. And that it returns the first matched key.

- Changing the underlying objects - the best solution I can think of is to
treat what we have previously considered invalid values as both key and
value. Thus
new Object[] {null, "abba", new Object[] {"foo", "bar"}}
has 3 key value entries:
null -> null
"abba" -> "abba"
"foo" -> "bar"

This way, the Map contents are always valid (ignoring the duplicate keys
issue, which cannot be solved)

- values, entrySet, keySet, iterator - implemented as best per the spec

However, before any work occurs, I'd like to ask other [lang] committers if
they agree that such a beast is still useful, or whether it is too loose.


----- Original Message -----
From: "Moritz Petersen" <>
To: "Jakarta Commons Developers List" <>
Sent: Monday, October 14, 2002 10:59 AM
Subject: RE: [lang] ArrayUtils toMap asMap, [was Re: [collections] [PATCH]

> Stephen,
> > By comparison with the JDK, the method asList(Object[]) is on
> > Arrays. Thus I
> > have applied the patch to ArrayUtils in [lang] instead of [collections].
> you're right, that makes sense.
> > When I looked at asMap(Object[]) I discovered certain problems that we
> > hadn't considered:
> > - the array doesn't behave like a Map when looking up keys because its
> > hashed
> Problem with this is, that asMap() returns the 'ArrayMap' object, that
> accesses the backup array. Hashing the keys would mean to create a new
> hashed representation of the array, and to keep it in sync with the actual
> keys. The question is, if it is worth it.
> > - what happens if someone changes the underlying array, to put an
> > object type or null into the array
> Operations on the array may be dangerous, after calling asMap(). Because
> returned ArrayMap is evaluated lazy, changes to the array are handled the
> same way as if they have been inside before calling asMap(): they will
> a NullPointerException or an IllegalArgumentException.
> If this is the desired response is questionable.
> > - the implementation didn't correctly handle the values(), entrySet() or
> > keySet() methods which should provide a view onto the real data
> > (which would
> > actually be tricky to implement).
> Indeed, that would be way more complicated than the current
> I think a little bit more effort would be reasonable. So, at least the
> point should be implemented for a correct behaviour.
> About the other I am not sure (especially at the first point I am not sure
> what the best way would be to handle it elegantly).
> -Moritz.
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message