[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652872#action_12652872
]
Hoss Man commented on LUCENE-1473:
----------------------------------
For the record: i have limited understanding of java serialization issues...
bq. At the risk of pissing off the Lucene powerhouse, I feel I have to express
some candor. I am growing more and more frustrated with the lack of the open
source nature of this project and its unwillingness to work with the developer
community.
The developer community consists of hundreds (possibly thousands) of people,
who participate at various levels. At the time the above quoted comment was
posted, 4 members of the community had expressed an opinion on this issue: 1
clearly in favor, and 3 questioning the advantages and disadvantages as they
affect the *whole* community, both in terms of the performance impacts for
existing use cases, and the long term support issues that might come from a
change like this.
How anyone could consider these comments and questions "unwillingness to work
with the developer community" blows my mind ... i do not see an overwhelming
push by the community at large for a feature, i do not see a "Lucene
powerhouse" arguing against the will of the masses ... I see two people arguing
in favor of a change, and three questioning whether this change is a good idea
(i'm not sure if i understand robert's post fully, i believe he's suggesting we
maintain the status quo such that serialization is supported but no claims are
made about back-compatible serialization).
I would define that as healthy discussion.
This, to me, seems to be the crux of the issue...
{quote}
Lucene, today, only guarantees "live serialization", and that's the
intention when "implements Serializable" is added to a class.
But, what's now being asked for (expected) with this issue is
"long-term persistence", which is really a very different beast and a
much taller order. With it comes a number of challenges, that warrant
scrutiny:
{quote}
...this jives with even my limited experience with java serialization, and i
share Michael's concerns. The current behavior does not appear to be a bug, it
appears to be the correct effects of a serializable class changing between two
versions w/o any explicit policy on serialization compatibility. The changes
being discussed seem to be a request for a new "feature": a back-compat
commitment on the serialization of one (or more) classes. However small the
patch may be, it's still a significant change that should not be made lightly
... I certainly think all 4 of Michael's bullet points should be clearly
addressed before committing anything, and I agree with Doug's earlier
observation regarding performance: we need to test that a new serialization
strategy won't adversely affect existing users who rely on (what Michael
refered to as) "live serialization".
This is my opinion. I voice it not as a member of any sort of mythical "Lucene
powerhouse" but as member of the Lucene community who is is concerned about
making sure that decisions are made towards "everyone's interest to make sure
Lucene grows in a healthy environment." -- not just the interests of two of
vocal people.
> Implement Externalizable in main top level searcher classes
> -----------------------------------------------------------
>
> 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: LUCENE-1473.patch
>
>
> To maintain serialization compatibility between Lucene versions, major
> classes can implement Externalizable. This will make Serialization faster
> due to no reflection required and maintain backwards compatibility.
--
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]
