You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2003/04/19 00:49:00 UTC

DO NOT REPLY [Bug 18068] - DefaultMapBag not Serializable

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18068>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18068

DefaultMapBag not Serializable

rwaldhoff@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|PatchAvailable              |
            Summary|HashBag not Serializable    |DefaultMapBag not
                   |                            |Serializable



------- Additional Comments From rwaldhoff@apache.org  2003-04-18 22:48 -------
There are two types in commons-collections that extend DefaultMapBag--HashBag
and TreeBag--and some unknown number of external classes that might extend from
this public class.  To make HashBag Serializable we'd have to make all of these
declared to be Serializable, which I'm not strictly opposed to but this isn't
necessarily a small change.  (note that I've changed the title of this bug to
reflect this.)

Alternatively, we'd have two branches of the DefaultMapBag tree, one for
Serializable types and one for non-Serializable types, similiar to the idiom
used, for example, in the o.a.c.collections.primitives.adapters package.  For
instance, AbstractIntCollectionCollection [1] provides the default methods but
contains no member variables, IntCollectionCollection [2] and
NonSerializableIntCollectionCollection [3] provide the member variables (in
serializable and non-serializable ways) but no behaviors.  This isn't especially
elegant, but it is functionally correct, and allows "implements Serializable" to
remain meaningful.

My personal preference is the "correct" approach, but I'm guessing this isn't
the only place in commons-collections where we get this wrong.

[1]
http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/java/org/apache/commons/collections/primitives/adapters/AbstractIntCollectionCollection.java?rev=HEAD
[2]
http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/java/org/apache/commons/collections/primitives/adapters/IntCollectionCollection.java?rev=HEAD
[3]
http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/java/org/apache/commons/collections/primitives/adapters/NonSerializableIntCollectionCollection.java?rev=HEAD

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org