I have described our use-case in good detail. I think it is a common architecture. And we are not using RemoteSearcher. This problem is not tied to RemoteSearcher, and we are not using RMI. Serialized java objects can be used at places other than RMI. "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." - does not make sense to me. There are lotsa bugs that are common, e.g. thread-safety, dead-lock, memory leak, and they are bad java, doesn't mean they should not be addressed.
Pardon me for being blunt, but this is really a bug: the expected behavior stated by the API is not honored. It would have been avoided if the same compiler was used for the release, with Java being WORA, this smells like a bug to me. My frustration is not unfounded, here are some examples I personally ran into: https://issues.apache.org/jira/browse/LUCENE-1246: simple 1 line null check, over 8 months, and still being "discussed" https://issues.apache.org/jira/browse/SOLR-243: with 4 votes, also few lines of change with the patch was originally done, over 18months, and still being "discussed" -John On Tue, Dec 2, 2008 at 3:43 PM, Mark Miller <[EMAIL PROTECTED]> wrote: > 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] > >
