[
https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221145#comment-13221145
]
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.
Fine!
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) comment
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: https://issues.apache.org/jira/browse/LUCENE-3795
> 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:
> http://code.google.com/p/lucene-spatial-playground/ 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
