lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: lucene API
Date Thu, 18 Aug 2005 19:00:40 GMT

On Aug 18, 2005, at 1:09 PM, Maros Ivanco wrote:
>> To:
>> From: Erik Hatcher <>
>> Date: 18.08.2005 3:45
>> Subject: Re: lucene API
>> When I first started digging into the Lucene codebase, I felt
>> similarly - the coding convention rule breaking drove me nuts.
>> Lucene grew on me and I've changed my take on "conventions"
>> dramatically thanks to Doug's explanations and the flavor he has
>> imparted onto the codebase.  His "conventions" have changed how I
>> code.
> Could you please point me to the discussion?

Please search the archives.  I don't have handy pointers to those  

>> There are sound reasons for the design of Lucene's
>> API and the (non)serializability of most pieces of it.
> What are they? Do they take into account integration with outside  
> world?

As was just said on this discussion, Lucene is a library.  And it's  
API does work quite well with the "outside world".  You're making it  
sound as if it is difficult to work with Lucene's API, when in fact  
it is extremely simple to work with.  If you need to wrap Lucene  
inside of JAX-RPC, then I recommend wrapping and perhaps simplifying  
the needed functions, not exposing them directly.

Lucene uses pointers back to the IndexReader, a transient connection  
to a (typical) file system resource.  This is done to allow Lucene to  
consume less system resources than pulling everything into RAM.  This  
is perhaps the main reason serializability of things is not done.

>>  What about
>> the Sourceforge Lucene web service project?  Would using that rather
>> than creating your own solution be reasonable?
> I have already looked at the project, but it implements only a part  
> of the
> search API. Unfortunately, I also need index reading and writing.

That project allows writing, at least from their documentation.

> Anyway, I have just finished the web service. It exposes most of  
> the Lucene
> API, so my problem is solved for now. But it is solved only partially,
> because changes to the API could break my wrapper classes (or
> de/serializers).

Lucene's public API does not change frequently, and when it does it  
first becomes deprecated and then only removed in a later version.   
So I don't think you have much risk of breakage with API changes.   
Besides, that is what unit tests are for!  :)  Drop in a new Lucene  
JAR, re-compile your code against, and re-run tests.

> So I would realy like to contribute and make Lucene more integrable.

We would love to have contributions to improve Lucene, no question.   
But it is important to understand the flavor of the community with  
respect to coding conventions and rationale - so be gentle, patient,  
but also aggressive with valuable suggestions :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message