[ https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654108#action_12654108 ]
Michael McCandless commented on LUCENE-1473: -------------------------------------------- {quote} > Often in the past was ensuring backwards-compatibility the part of > writing patches that took the longest and involved the most > discussions. {quote} It very much still is, as I'm learning with LUCENE-1458! Your first example is missing the read/writeExternal methods. I think the proposed approach is rather heavy-weight -- we will have implemented readExternal, writeExternal, this new CustomExtenralizableReader, package private init methods, make private inner classes package private, the need to javadoc specifically the current externalization format written for each of our classes, the future need to help users to understand how they an achieve back compatibility by subclassing CustomExternalizableReader, etc. I guess my feeling is all of that is a good amount more work than just deciding to directly implement back compatibility, ourselves. EG, to do your example in a future world where we do support back compat of serialized classes (NOTE -- none of the code below is compiled/tested): First a util class for managing versions: {code} public class Versions { private int current; int add(String desc) { // TODO: do something more interesting with desc return current++; } void write(ObjectOutput out) throws IOException { // TODO: writeVInt out.writeByte((byte) current); } void read(ObjectInput in) throws IOException { // TODO: readVInt final byte version = in.readByte(); if (version > current) throw new IOException("this object was serialized by a newer version of Lucene (got " + version + " but expected <= " + current + ")"); } } {code} Then, someone creates SomeClass: {code} public class SomeClass implements Externalizable { private int one; private int two; private static final Versions versions = new Versions(); private static final int VERSION0 = versions.add("start"); public SomeClass() {}; public void writeExternal(ObjectOutput out) throws IOException { versions.write(out); out.writeInt(one); out.writeInt(two); } public void readExternal(ObjectInput in) throws IOException { versions.read(in); one = in.readInt(); two = in.readInt(); } ... } {code} Then on adding field three: {code} public class SomeClass implements Externalizable { private int one; private int two; private int three; private static final Versions versions = new Versions(); private static final int VERSION0 = versions.add("start"); private static final int VERSION1 = versions.add("the new field three"); public SomeClass() {}; public void writeExternal(ObjectOutput out) throws IOException { versions.write(out); out.writeInt(one); out.writeInt(two); } public void readExternal(ObjectInput in) throws IOException { int version = versions.read(in); one = in.readInt(); two = in.readInt(); if (version >= VERSION1) three = in.readInt(); else // default three = -3; } ... } {code} In fact I think we should switch to Versions utils class for writing/reading our index files... > Implement standard Serialization across Lucene versions > ------------------------------------------------------- > > Key: LUCENE-1473 > URL: https://issues.apache.org/jira/browse/LUCENE-1473 > Project: Lucene - Java > Issue Type: Bug > Components: Search > Affects Versions: 2.4 > Reporter: Jason Rutherglen > Priority: Minor > Attachments: custom-externalizable-reader.patch, LUCENE-1473.patch, > LUCENE-1473.patch, LUCENE-1473.patch, LUCENE-1473.patch > > Original Estimate: 8h > Remaining Estimate: 8h > > To maintain serialization compatibility between Lucene versions, > serialVersionUID needs to be added to classes that implement > java.io.Serializable. java.io.Externalizable may be implemented in classes > for faster performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]