lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Halácsy Péter <>
Subject RE: why is document final
Date Mon, 15 Apr 2002 22:55:30 GMT

> -----Original Message-----
> From: []
> Sent: Thursday, April 11, 2002 8:00 PM
> To:
> Subject: RE: why is document final
> > From: Halácsy Péter
> > 
> > could someone explain why Document is final? 
> Because it was not designed to be subclassed.
> When I wrote Lucene I only made classes non-final that I 
> expected end users
> to need to subclass.  In the case of Document, this is 
> perhaps overkill, but
> I prefer to have folks try to first use Lucene the way it is 
> intended.  This
> results in fewer spurious bug reports.
IndexWriter is final: I wanted to implement a BatchIndexWriter that adds documents first in
a ram directory and after a while adds to a FSDirectory (as you suggested:

Searcher can't be subclassed (from other package than because it
has package protected abstract methods. I wanted to implement a ManagedSearcher class (something
like PooledConnection) that can be used in conjuction with IndexAccessControl (

> Why do you need to subclass Document?
I was wondering if I could make a class representing object of my application that are documents
(--> extends Document). For example in the demo app org.apache.lucene.demo.FileDocument
is not a Document, only a static factory class. It would be much object oriented to have a
FileDocument as
public FileDocument extends Document {
   public FileDocument(File file) throws IOException {
      add(Field.Text("path", f.getPath()));
      FileInputStream is = new FileInputStream(f);
      Reader reader = new BufferedReader(new InputStreamReader(is));
     add(Field.Text("contents", reader));

On the other hand I can imagine that IndexWriter.addDocument saves the type of Document as
ObjectOutputStream does. Example
EmailDocument ed = new EmailDocument(from, to, subject, body, time);
Hits hits =;
EmailDocument ed = (EmailDocument) hits.doc(1);

I can package the object/index mapping logic into the EmailDocument class.


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

View raw message