[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653001#action_12653001
]
Jason Rutherglen commented on LUCENE-1473:
------------------------------------------
The discussion has evolved out of scope. Cross-version compatibility is the
main goal. We have multiple versions of Lucene using the Spring RPC protocol.
The standard way to solve this is add a serialVersionUID like HashMap, String,
and the other Java classes do.
Performance is a topic of concern for Lucene users and existing
RMI/Serialization users would transparently benefit by Externalizable being
used.
I would like to implement this as a separate project, however performing
reflection on each of the objects is not an efficient approach. Writing
wrapper code for each and every variation of Query is a waste of time when it
implements Serializable and the communication is between Java systems.
It seems best to remove Serialization from Lucene so that users are not
confused and create a better solution.
> Perhaps most Lucene developers are not using dynamic class loading,
Dynamic classloading is popular and accepted in J2EE servers. If done properly
it is a very convenient way of deploying Java based systems. Jini did not make
this convenient enough. Jini did not have a specific problem it was trying to
solve and so was too complex and open ended. Spring and J2EE make use of Java
serialization for distributed objects. People may not be using Lucene for this
today but this is due largely to lack of support for things like standard
Serialization. With Lucene it is possible to make dynamic search classloading
convenient in a search grid environment.
When J2EE was designed, no one was using Java on the server side. A framework
was composed and a handful of companies implemented the specification and then
found it's way into projects. If you are looking for users to ask for
something that does not exist like this, it will not happen.
The interface Lucene exposes is relatively static and known. All of the top
level classes, Query, Analyzer, Document, Similarity do not change very often.
In a search based grid computing environment, the ability to execute arbitrary
code against the cloud saves time and effort in deploying new code to servers.
Restarting processes in a production environment is always expensive. If one
is implementing for example mutating genetic algorithms using Java over Lucene
then it would be advantageous to dynamically load the classes that implement
this. They would be modifications of several classes such as Query,
Similarity.
It is peculiar all the effort that goes into backwards compatibility of the
index, but for Serialization it is ignored. This is and will be very confusing
to users, especially ones who use J2EE.
> 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]
