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? 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. > 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. > 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. > 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. > 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 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
