I prefer Externalizable as well as it makes Serialization faster. Perhaps
also for Query and it's subclasses to start? I had code to do this for
Analyzer as well which could be useful, perhaps a different patch though.
On Tue, Dec 2, 2008 at 2:22 AM, Michael McCandless <
[EMAIL PROTECTED]> wrote
Karl Wettin wrote:
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
Jason Rutherglen wrote:
Hi Mike,
Can you build and release a 2.4 jar using the 2.3 build environment?
I don't think that's the right approach here. We should, instead,
directly fix Term.java to be serializable, if that's the goal.
(Or, as a workaround, Karl's suggestion that you build y
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
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 <
[EMAIL P
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
> 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 deci
Well.. if you don't set serialVersionUID yourself, then java assigns a
rather volatile one for you so that it doesn't attempt to deserialize
to an incompatible local class.
We could assign one ourselves, and then we have to remember to change
it if we ever make a big enough change to Term, to al
Seeing the following issue between Lucene 2.3 and 2.4. A 2.3 serialized Term
object cannot be deserialized by 2.4. I would guess it has something to do
with a different Java compiler being used for the Lucene 2.4 build as
serialVersionUID is not defined in the Term class. Fixing the issue is
crit
