commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Smith" <>
Subject Re: [Collections] non-compatible changes
Date Thu, 21 Mar 2002 19:26:47 GMT
On Thu, 21 Mar 2002, Morgan Delagrange wrote:
> > 3. BeanMap.values() is modifiable, but modifications are not reflected in
> > the BeanMap.  Probably should return an unmodifiable collection.
> >
> > 4. BeanMap.keySet() is modifiable.  Modifications to it (i.e. removes)
> > will be reflected in the BeanMap, but that's probably not a good idea.
> > Probably should return an unmodifiable collection.
> I'm -1 to these changes.  There may be clients to BeanMap that expect this
> behaviour, and I'm uncomfortable with changing it in the eleventh hour of
> the release.  I think that, for now, we should just document the behavior in
> the Javadocs.

So, you'd rather leave the behavior such that changes to keySet() are 
reflected in the map, entrySet() is unmodifiable, and changes to values() 
are not reflected in the map?  Having three different behaviors for these 
just seems wrong to me as well. 

> > 5. DoubleOrderedMap requires its keys and elements to be comparable.  I
> > don't think the external API relies on Comparable (just the internal API),
> > so I don't think this must be fixed before a 2.0 release, but I didn't
> > look quite that closely to know for sure.
> >
> > 6. The following classes have "protected" members and/or methods, but
> > the ability to subclass without "corrupting" the internal state of
> > the parent class is suspect: BeanMap, FastArrayList, FastHashMap,
> > FastTreeMap.  Fixing these would probably involve making some fields
> > private.
> -1.  We should minimize changes that affect Serialization, and in this case
> it doesn't seem worth the price.

I don't know how either of these have effects on Serialization.  

DoubleOrderedMap isn't serializable, and even if it was, it doesn't have 
any Comparable fields that would be serialized (all the Comparable 
references are casts in order to do a comparison).  

As for changing protected members to private or otherwise adjusting to 
ensure subclasses can't corrupt internal structures, that doesn't change 
serialization either.  If anything, it just requires the addition of a 
serialVersionUID to say "yes, this class really does have the same 


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

View raw message