commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morgan Delagrange" <mdela...@yahoo.com>
Subject Re: Collections 1.1?
Date Tue, 19 Feb 2002 07:30:16 GMT

----- Original Message -----
From: "Michael Smith" <michael@iammichael.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>;
"Morgan Delagrange" <morgand@apache.org>
Sent: Tuesday, February 19, 2002 12:54 AM
Subject: RE: Collections 1.1?


> Morgan Delagrange wrote:
> > Don't sweat it.  Before you sent me your update, I tried to
> > write a unit
> > test for serialization against the old code, and it appears that
> > de-serialization doesn't work for the old version of SequencedHashMap
> > (unless I goofed somewhere).  I tried the test against the
> > new code too.  It
> > just throws an exception at serialization time, saying that
> > the class is
> > incompatible for serialization.  That's pretty obvious; there
> > are inner
> > classes that don't implement Serializable.
>
> Yeah, my version doesn't have the Map.Entry objects implementing
> Serializable.  :)  I'm not sure why you couldn't deserialize the old
> version though.  Looking at the old code, I don't see any obvious
> problems.  What did you mean by "de-serialization doesn't work"?  Was it
> throwing exceptions or something?

Yup a NullPointerException when it tried to perform a put operation for some
reason (probably as a result of specialized code in a superclass.  I didn't
try too hard, because I knew it wasn't a big issue.

> I guess this doesn't matter too much
> because:
>
> > And here's the real kicker...SequencedHashMap is new to 1.1.  :)
>
> SequencedHashMap didn't exist in 1.0?  huh...  that would certainly
> explain why It's not listed in the on-line API docs.
>
> If that's really the case, I'd like to remove the fact that it extends
> from HashMap and instead have it extend from AbstractMap (I think I
> mentioned that in my documentation).  Ideally, I think it'd be better to
> implement the full interface and just implement the Map interface
> without a super class.  I'll add that to my list of things to do.

Sounds good.

> > Before the 1.1 release, however, it might we worthwhile to give
> > SequencedHashMap an Externalizable form, so that it _can_ be
> > externalized in
> > a data format that's easy to maintain.  You should be able to adopt a
> > technique similar to LRUMap's format without too much trouble, I would
> > think.
>
> agreed.  I'll work on that this week.  Work has been taking quite a bit
> of my time, so I haven't had a chance to "play" much recently.
> Hopefully I'll be able to get to it.

Cool.  Maybe I'll take a look too, if I get a chance.

> > Yes I would agree that changes to serialized forms would
> > require a Major
> > Revision in all cases, if that class is in the External
> > Interface and the
> > product does not specifically forbid serialization in the
> > documentation.
>
> The document may want to mention that.  :)  If you don't get a chance,
> I'll see if I can write up something and send in a patch.

The document implies it, but it could use some clarification.

> > I've written an externalization unit test for LRUMap.java,
> > and I attempted
> > to write one for SequencedHashMap.  It's probably a good idea
> > to create unit
> > tests for the other collections as well.  My approach was
> > pretty simple:
> > create the collection from the 1.0 release code (or the HEAD, if the
> > collection is new), serialize/externalize it to disk at the path
> > "data/test/<collection_name>Version1.obj", and write a unit test that
> > attempts to de-serialize and read the object.
>
> Probably need to create at least two serialized forms of the object.  An
> empty collection, and one with data in.  Preferrably a number of forms
> with data.  Especially if we write our own serialization/externalization
> routines; we'll want to check many various serialization scenarios.

Yup, if you wanted to be thorough.  At a minimum, you'd want one serialized
Object with data.  You might also want to serialize and deserialize in
memory as well, to insure that the current code can also serialize correctly
rather than just checking backwards-compatible deserialization.  Whew.

It might be a good idea to add some utility methods to TestMap to make these
operations available everywhere.

> > Actually, I want to work a little more on that versioning
> > document.  I think
> > it could use a little tightening and clarification.  In
> > particular, it might
> > be good to generate a short glossary of very specific terms to use
> > throughout the document, particularly with regard to projects, their
> > products, and the contracts those products enforce.  I've copied that
> > versioning.xml document to the jakarta-site2 repository (per
> > Jason van Zyl's
> > request), where I hope to spruce it up some and propose its
> > adoption in
> > several projects, including Commons and Taglibs.  Everyone is
> > welcome to
> > participate, if you have ideas.
>
> I have ideas, just not much time to write them down in sentances that
> make sense.  :)
>
> > Good work on the SequencedHashMap.  So far it looks pretty good to me.
>
> thanks!
>
> regards,
> michael
>

- Morgan



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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


Mime
View raw message