----- Original Message ----- From: "Michael Smith" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Morgan Delagrange" <[EMAIL PROTECTED]> Sent: Monday, February 18, 2002 9:32 PM Subject: RE: Collections 1.1?
> Morgan Delagrange wrote: > > AFAIK SequencedHashMap has never implemented Externalizable. Right? > > It does implement Serializable though. Albeit indirectly. The > implementation extends from HashMap which is serializable. I didn't > realize that when I first implemented my new version. 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. And here's the real kicker...SequencedHashMap is new to 1.1. :) 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. > This brings up an interesting issue though. The Commons versioning > document does not specify how "serialization" or "externalization" are > handled. Instead, the versioning standard is centered around the API > contracts (i.e. the method signatures). > > For reference: http://jakarta.apache.org/commons/versioning.html Hey, that document looks familiar. :) > Going to 2.0 would be considered a "major releases" which is required > when "a new release is not at least interface-compatible". > "Interface-compatible" is defined as one which will "at most change the > private interface of a component, or simply add classes, methods and > attributes whose use is optional to both internal and external interface > clients." There are two things to note here: 1) nothing about > serialization/externalization is mentioned, and 2) the addition of > optional attributes is interface compatible. Adding additional > attributes usually requires additional fields, and probably includes a > change in the serialized form, yet this is still listed as > interface-compatible. > > In general though, I think that being serializable or Externalizable is > something that needs to be maintained for full backwards compatibility. > The versioning document just seems to completely overlook that. > > What are people's thoughts on this? Does a serialization change require > a Major revision change? Or is a Minor revision change acceptable > provided the serialization incompatibilities are noted in the > documentation? Does your opinion change for classes that directly > implement Serializable or Externalizable vs classes that inadvertantly > inherited the interface? 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. 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. 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. > regards, > michael > Good work on the SequencedHashMap. So far it looks pretty good to me. - Morgan _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
