From java-user-return-37451-apmail-lucene-java-user-archive=lucene.apache.org@lucene.apache.org Tue Dec 02 04:43:57 2008 Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 99151 invoked from network); 2 Dec 2008 04:43:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Dec 2008 04:43:57 -0000 Received: (qmail 87103 invoked by uid 500); 2 Dec 2008 04:44:01 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 87069 invoked by uid 500); 2 Dec 2008 04:44:01 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 87058 invoked by uid 99); 2 Dec 2008 04:44:01 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 20:44:01 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of karl.wettin@gmail.com designates 66.249.90.177 as permitted sender) Received: from [66.249.90.177] (HELO ik-out-1112.google.com) (66.249.90.177) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2008 04:42:32 +0000 Received: by ik-out-1112.google.com with SMTP id c29so2314910ika.5 for ; Mon, 01 Dec 2008 20:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=igSWmStm5kdImvIiUOWEjG07RcWB/lBzKFJfdR9iN0U=; b=aRU5wgXsC2pKj+bndOKj9DGC6nSQC8nYQ7ljfkKsvM5ojuTT4gdfSc56cY22O9++q+ XQupy3cfF6fo/O4s4PrWio3rUk2AOwT5Wv2i8cxmn1vb5LN1R0WWkG332UO+9b4vyBC/ JJ7VSCJmu8HoH9Kygr78CwJhQvC08NAMmp3bY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=jP/SW/BpV4ZwaLSDpXV/yJYepa9zkhvZ+yEObcAti+o0+tjkBlmqQwZbSEvnOhp+5c /xibqrCaOGoCabvPN38Vup8aIWt43o9/hAEGv6UoZy7XjRUDMKqeSHxXJyNJehqe2S/c CTwitHmYZyIfPXePummzpXEgRaSd4Jnsb19ns= Received: by 10.210.105.20 with SMTP id d20mr13481240ebc.142.1228192988314; Mon, 01 Dec 2008 20:43:08 -0800 (PST) Received: from kodapan.lan (c150-155-70-80.bjare.net [80.70.155.150]) by mx.google.com with ESMTPS id f6sm25185548nfh.12.2008.12.01.20.43.03 (version=SSLv3 cipher=RC4-MD5); Mon, 01 Dec 2008 20:43:05 -0800 (PST) Message-Id: From: Karl Wettin To: java-user@lucene.apache.org In-Reply-To: <85d3c3b60812011818k178f3b0apc213c1ea80136713@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: serialVersionUID issue between 2.3 and 2.4 Date: Tue, 2 Dec 2008 05:42:46 +0100 References: <85d3c3b60812011517x3f0f4589ld18fe6bdea9b659f@mail.gmail.com> <9D626FCD-5660-4590-BA3D-E7D7CC3D9B8C@mikemccandless.com> <85d3c3b60812011754o5b2a7779obce92f61508092fe@mail.gmail.com> <85d3c3b60812011818k178f3b0apc213c1ea80136713@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Checked: Checked by ClamAV on apache.org You could get the 2.4 code and set the serialVersionUID of the Term class to the UID assigned to the 2.3 Term class (554776219862331599l) and recompile. As for statically setting a serialVersionUID in the class, one could instead set it to a final value and implement Externalizable in order to keep binary compatibility between class versions that contains more changes than what the Serializable reflection support code can handle. That would also save a few clock ticks. All over I think that is a much better solution. karl 2 dec 2008 kl. 03.18 skrev Jason Rutherglen: > Hi Mike, > > Can you build and release a 2.4 jar using the 2.3 build environment? > >> Besides having to remember to change the serialVersionUID, are >> there any > known downsides to setting it explicitly? > > As far as I know it's all good. > > Jason > > On Mon, Dec 1, 2008 at 6:11 PM, Michael McCandless < > lucene@mikemccandless.com> wrote: > >> >> Jason Rutherglen wrote: >> >> if you don't set serialVersionUID yourself, then java assigns a >>>> >>> rather volatile one for you >>> >>> True however the Java specification defines how the serialVersionUID >>> should >>> be created in the event it's not defined. The caveat being it's not >>> strictly enforced and so Sun alternative compilers may decide to >>> change >>> how >>> it's created (from what I've read). Base classes like Term and >>> Query >>> don't >>> change very often so we may want to settle on a serialVersionUID >>> for these >>> top level classes. >>> >> >> Makes sense. Besides having to remember to change the >> serialVersionUID, >> are >> there any known downsides to setting it explicitly? >> >> Lucene sets it for 2 sources now (RAMFile & RAMDirectory). >> >> Was a different compiler used for the 2.4 release compared to 2.3? >>> >> >> Likely, yes (two different people, Michael and Mike (me!), in >> different >> envs, >> did the releases). >> >> Mike >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org >> For additional commands, e-mail: java-user-help@lucene.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org