Woah! I think you got the wrong impression. I think Doug said
basically what I was thinking (if not a bit more clearly than I was
thinking it). I think we are all open to any good patches. It's nice
to understand and discuss them first though.
To reiterate what doug mentioned, sometime you IMp serializable for
RMI but you don't want to fully support it. Mabye it's not great java,
but it's common enough, and makes sense to me in certain instances.
- Mark
On Dec 2, 2008, at 6:30 PM, "John Wang (JIRA)" <[EMAIL PROTECTED]> wrote:
[ https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652594#action_12652594
]
John Wang commented on LUCENE-1473:
-----------------------------------
the fact an object implements Serializable implies this object can
be serialized. It is a known good java programming practice to
include a suid to the class (as a static variable) when the object
declares itself to be Serializable. If it is not meant to be
serialized, why did it implement Serializable. Furthermore, what is
the reason to avoid it being serialized? I find the reason being the
cost of support kinda ridiculous, seems this reason can be applied
to any bug fix, because this at the end of the day, it is a bug.
I don't understand the issue of "extra bytes" to the term dictionary
if the Term instance is not actually serialized to the index (at
least I really hope that is not done)
The serialVersionUID (suid) is a long because it is a java thing.
Here is a link to some information on the subject:
http://java.sun.com/developer/technicalArticles/Programming/serialization/
Use case: deploying lucene in a distributed environment, we have a
broker/server architecture. (standard stuff), we want roll out
search servers with lucene 2.4 instance by instance. The problem is
that the broker is sending a Query object to the searcher via java
serialization at the server level, and the broker is running 2.3.
And because of specifically this problem, 2.3 brokers cannot to talk
to 2.4 search servers even when the Query object was not changed.
To me, this is a very valid use-case. The problem was two different
people did the release with different compilers.
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. This is a rather trivial
issue, and it is taking 7 back-and-forth's to reiterate some
standard Java behavior that has been around for years.
Lucene is a great project and has enjoyed great success, and I think
it is to everyone's interest to make sure Lucene grows in a healthy
environment.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
