lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
Date Fri, 02 Mar 2012 18:49:57 GMT


Uwe Schindler commented on LUCENE-3795:

bq. Commons-lang is used by both Spatial4J and the new spatial-module. This dependency can
easily be severed and will happen shortly.


bq. SLF4j is used by both Spatial4J and the new spatial-module. I really like SLF4J but all
this resistance to remove dependencies leads me to compromise, and I'll find a way to removing
it or have it as an optional dependency.

In my opinion, non-end-user components should not log, which affects libraries. E.g. there
is nothing in the JDK to enable logging of the JDK itsself, although there are surely parts
that could log something. Lucene is the same, it does not need to log anything, the client
code should log things like "now executing term query..." and so on. IndexWriter is a little
bit special, it has now a simple "log-like" interface for debugging (consisting of abstract
InfoStream class). This class can be implemented by a logging framework, but would slowdown
indexing immense, as logging frameworks tend to use volatiles on every log request (even when
not logging).

So I strongly recommend to remove logging. For debugging we often comment out System.out.println
inside Lucene.

bq. Uwe and others, the rationale for a core spatial library off of Lucene is my last (long)

OK, OK. I still don't understand the whole rationale to move it outside Lucene or to a separate
module. Everybody can use the classes by adding the JAR file, too. The "useless" lucene classes
don't hurt. Still I would strongly recommend to use parts of lucene.util package whereever
possible, especially when performance and easy Lucene integration is needed. So dont create
Strings all the time, use BytesRef and index/search using *binary* terms like NumericField
does in Lucene trunk. If this module outside Lucene uses Strings all the time, but e.g. when
indexing searching all those strings are again converted to UTF-8 BytesRefs, thats a laaaaaaaaaaaaaaarge
overhead. So I prefer to sometimes duplicate code and add performant impls of e.g. term encoders
for indexing/search. Every method in Lucene that is used in tight loops (like scorers or TokenStreams)
should never ever use Strings (which are final and unmodifiable).
> Replace spatial contrib module with LSP's spatial-lucene module
> ---------------------------------------------------------------
>                 Key: LUCENE-3795
>                 URL:
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: modules/spatial
>            Reporter: David Smiley
>            Assignee: David Smiley
>             Fix For: 4.0
> I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module
within Lucene Spatial Playground (LSP).  LSP has been in development for approximately 1 year
by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready.  LSP is here:
 and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/.
> I'll add more comments to prevent the issue description from being too long.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


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

View raw message