After all the good reviews and very positive feedback about Lucene in Action that we have received over the last 10 months, we finally came across a not so positive review . The review can be broken down into the following 4 main parts:

  1. Lack of import statements
  2. Authors didn't test the code
  3. OOP is not suitable for Lucene code examples and there are no direct Lucene calls
  4. Need for a command-line tool for HTML indexing

As Amazon's site doesn't let us provide feedback and respond to the review there, we thought we would address these issues here and hopefully help the reviewer get more out of our book. Let's address each of the four concerns:

  1. Lack of import statements

    Code examples in the book purposely don't contain import statements. Often times the list of import statements would be rather long. If we included all the imports, the code examples would be much longer and would often span multiple pages, thus making them harder for readers to follow. The list of import statements would also often repeat, as most examples import the same or very similar set of Lucene classes. Including imports would result in a thicker, heavier, and thus more expensive book.

    So how should one deal with the lack of import statements?

    Firstly, all code examples from Lucene in Action are free and available for download, even for those who don't own a copy of the book. The code is packaged with an ant script that can compile all the code, create all needed indexes, and run the code examples from the book.

    Secondly, one can import all the code in any modern Java IDE and easily see which classes come from which packages.

    This is also described in the book itself, in the "About the Book" section on page xxvii, in the last sentence in the paragraph titled "Code examples".

  2. Authors didn't test the code

    One of the novel and interesting aspects of Lucene in Action is that most of its code examples are written as unit tests. All code examples are, therefore, automatically tested. We used the excellent JUnit unit test framework to build the examples, and we provided the reasoning behind this in the "About the Book" section on page xxvii, in the paragraph titled "Why JUnit?".

  3. OOP is not suitable for Lucene code examples and there are no direct Lucene calls

    All the calls to Lucene are direct calls, but presented as unit tests. It sounds like the reviewer is confusing OOP and unit tests.

  4. Need for a command-line tool for HTML indexing

    We present just such a tool in Chapter 7, in section 7.4.2. The chapter also includes a whole mini-framework for indexing other file types (e.g. XML, Word, PDF, etc.).

Posted on Wed, 21 Sep 2005 05:47