commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morgan Delagrange" <>
Subject Re: [Collections] non-compatible changes
Date Thu, 21 Mar 2002 20:13:13 GMT

----- Original Message -----
From: "Michael A. Smith" <>
To: "Morgan Delagrange" <>
Cc: "Jakarta Commons Developers List" <>
Sent: Thursday, March 21, 2002 1:26 PM
Subject: Re: [Collections] non-compatible changes

> On Thu, 21 Mar 2002, Morgan Delagrange wrote:
> > > 3. BeanMap.values() is modifiable, but modifications are not reflected
> > > 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
> > behaviour, and I'm uncomfortable with changing it in the eleventh hour
> > 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.

It's not ideal, but it's a little late in the game to change it.  I've
updated the documentation to point out this behaviour.  (Also, the fact that
changes to the keySet() are reflected by the Map is in keeping with the
general contract for Map.)

I would be willing to retract my -1 if you got buy-in from James and there
were no other objections.  However, if we're going to fix it, let's make it
agree with the Map contract.  Personally, changing it at this point makes me
uncomfortable, and I'd rather not do it.

> > > 5. DoubleOrderedMap requires its keys and elements to be comparable.
> > > don't think the external API relies on Comparable (just the internal
> > > 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
> > 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).

I didn't mean to refer to #5, since you aren't proposing any changes.

> 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
> fields".

If you take care to preserve Serialization, that would be a plus.  (I'm far
from the world's expert on Serialization  :)  But what about existing
subclasses?  I cannot say with certainty that such subclasses do not exist
and do not rely on methods we currently expose.  We can insert warnings in
the Javadocs, but changing the interface seems premature.

> regards,
> michael
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do You Yahoo!?
Get your free address at

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

View raw message