Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of john.wang@gmail.com
 designates 209.85.217.10 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=hqSgwOihbzEwXqOT8KCkFuQBrXOgPHH0+Pn4/tq2xHHyitWYXrOqgrtaDeYcdMnqS2
         tayF0DSjbcMVxlVpOMmOkVUxK+zu9Kv5j/e7jRpjHRupRXmZj5fkLNnpOK4iNvY2No7m
         +5+UKDQxcByI41PM80sPqJDI08ZOmGDFOcGPI=
Message-ID: <8837fb770812051310v628c1094te3e42c569305e8b7@mail.gmail.com>
Date: Fri, 5 Dec 2008 13:10:02 -0800
From: "John Wang" <john.wang@gmail.com>
To: java-dev@lucene.apache.org
Subject: Re: [jira] Commented: (LUCENE-1473) Implement Externalizable in main
 top level searcher classes
In-Reply-To: <39BDE566-C691-4289-809D-BB12C0577268@mikemccandless.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_131190_10495544.1228511403074"
References: <285450834.1228332464360.JavaMail.jira@brutus>
	 <57AB459A-5FD8-4F90-8D04-E0EC170A5FEF@apache.org>
	 <85d3c3b60812041121p3e4e79a9tb7c1a44c3a37d3e@mail.gmail.com>
	 <A627AFDA-98F6-4FFD-97F6-AA6EFE9DE1EF@apache.org>
	 <8837fb770812041618n25767ba6k9f730387381f4d41@mail.gmail.com>
	 <49396272.3060904@apache.org>
	 <8837fb770812051123u35c0e969ld8e0f41a828de9a@mail.gmail.com>
	 <39BDE566-C691-4289-809D-BB12C0577268@mikemccandless.com>

------=_Part_131190_10495544.1228511403074
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Mike:
       This has been gone back and forth on this thread already. Again, I
agree it is not the perfect solution. I am comparing that to the current
behavior, I don't think it is worse. (Only in my opinion).

       "live serialization" is not familiar to me. To understand it more,
can you point me to somewhere the J2EE spec defines it? AFAIK, the J2EE spec
does not make a distinction, and from what I gather from this thread, Lucene
does not fall into the special category on how Serializable is used. Of
course, it could just be my lack of understanding in the spec.

       We are happy to accept whatever you guys think on this issue. As it
is currently, it is not consistent amongst different committers.

Thanks

-John

On Fri, Dec 5, 2008 at 12:07 PM, Michael McCandless <
lucene@mikemccandless.com> wrote:

>
> John Wang wrote:
>
>  My proposal is to add the suid to Serializable classes
>>
>
> That's too brittle.
>
> If we do that, then what happens when we need to add a field to the
> class (eg, in 2.9 we've replaced "inclusive" in RangeQuery with
> "includeLower" and "includeUpper")?  The standard answer is you bump
> the suid, but, then that breaks back compatibility.
>
> Since we would still sometimes, unpredictably, break back
> compatibility, no app could rely on it.  You can't have a "mostly
> back compatible" promise.
>
> So... we have to either 1) only support "live serialization" and
> update the javadocs saying so, or 2) support full back compat of
> serialized classes and spell out the actual policy, make thorough
> tests for it, etc.
>
> Mike
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

------=_Part_131190_10495544.1228511403074
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Mike:<div><br></div><div>&nbsp;&nbsp; &nbsp; &nbsp; This has been gone back and forth on this thread already. Again, I agree it is not the perfect solution. I am comparing that to the current behavior, I don&#39;t think it is worse. (Only in my opinion).</div>
<div><br></div><div>&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&quot;live serialization&quot; is not familiar to me. To understand it more, can you point me to somewhere the J2EE spec defines it? AFAIK, the J2EE spec does not make a distinction, and from what I gather from this thread, Lucene does not fall into the special category on how Serializable is used. Of course, it could just be my lack of understanding in the spec.</div>
<div><br></div><div>&nbsp;&nbsp; &nbsp; &nbsp; We are happy to accept whatever you guys think on this issue. As it is currently, it is not consistent amongst different committers.&nbsp;</div><div><br></div><div>Thanks</div><div><br></div><div>-John</div>
<div><br><div class="gmail_quote">On Fri, Dec 5, 2008 at 12:07 PM, Michael McCandless <span dir="ltr">&lt;<a href="mailto:lucene@mikemccandless.com">lucene@mikemccandless.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d"><br>
John Wang wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My proposal is to add the suid to Serializable classes<br>
</blockquote>
<br></div>
That&#39;s too brittle.<br>
<br>
If we do that, then what happens when we need to add a field to the<br>
class (eg, in 2.9 we&#39;ve replaced &quot;inclusive&quot; in RangeQuery with<br>
&quot;includeLower&quot; and &quot;includeUpper&quot;)? &nbsp;The standard answer is you bump<br>
the suid, but, then that breaks back compatibility.<br>
<br>
Since we would still sometimes, unpredictably, break back<br>
compatibility, no app could rely on it. &nbsp;You can&#39;t have a &quot;mostly<br>
back compatible&quot; promise.<br>
<br>
So... we have to either 1) only support &quot;live serialization&quot; and<br>
update the javadocs saying so, or 2) support full back compat of<br>
serialized classes and spell out the actual policy, make thorough<br>
tests for it, etc.<br>
<br>
Mike<div><div></div><div class="Wj3C7c"><br>
<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe, e-mail: <a href="mailto:java-dev-unsubscribe@lucene.apache.org" target="_blank">java-dev-unsubscribe@lucene.apache.org</a><br>
For additional commands, e-mail: <a href="mailto:java-dev-help@lucene.apache.org" target="_blank">java-dev-help@lucene.apache.org</a><br>
<br>
</div></div></blockquote></div><br></div>

------=_Part_131190_10495544.1228511403074--