I worked on getting both of thoses issues resolved :) Sorry, can't
please everyone. If it helps, I'll commit that second one soon now
that I can. It's lazy consensus around here man. Mabye it's not ideal,
but I think the product speaks well for itself so far. I've never met
a more accomadating group of guys myself. It is a large part volunteer
effort.
- Mark
On Dec 2, 2008, at 7:02 PM, "John Wang" <[EMAIL PROTECTED]> wrote:
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]
