lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Wang" <>
Subject Re: [jira] Commented: (LUCENE-1473) Implement Externalizable in main top level searcher classes
Date Wed, 03 Dec 2008 00:22:48 GMT
If you guys need help, maybe you guys should expand your committer list?
"product speaks well for itself so far", from what I have heard, losta
people are just branching off the code-base and making changes and do merges
every release. I really don't want to do that here, but I am being forced
down that road. What I think should be avoided what happened to Linux, where
there are different versions of the kernel, e.g. there are different version
of lucene projects.

Don't get me wrong, I think it is one of the best projects out there. But
sometimes I think you guys should listen to the community a bit more,
instead of presuming how the product is used.

Anyway, thanks for looking into those issues.


On Tue, Dec 2, 2008 at 4:11 PM, Mark Miller <> wrote:

> 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" <> 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:
> <>
> simple 1 line null
> check, over 8 months, and still being "discussed"
> <>
> 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 < <>
>> 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)" < <>
>>> wrote:
>>>   [
>>> <>
>>>  ]
>>> 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:
>>> <>
>>> 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: <>
>>>>           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: <>
>>> For additional commands, e-mail: <>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: <>
>> For additional commands, e-mail: <>

View raw message