關於lucene發展和多語言實現的方向 多語言lucene的發展無疑是基於java lucene的。一切的功能特性和兼容性的問題都要以java lucene為主。Java lucene是其他語言lucene發展的鼻祖。那麼多語言lucene的發展應該怎麼辦呢？看看下面的文字吧：
There is a concerted effort to develop a SWIG Lucene and there is also a CLucene and an active Lucene4C project. I was crazy enough to contemplate a native Ruby port once upon a time, and developed some low-level I/O code and then realized what a maintenance hassle it'd be to keep up with the always evolving Java Lucene.The PyLucene crew (credit where its due, Andi Vajda!) did something quite amazing... using GCJ and SWIG to interface Java Lucene with Python. This, in my opinion, is the way to future "ports" to any language. Let Java Lucene be the base and all other ports derive from it. I'm not sure why motivates Garrett with Lucene4C - and I certainly do not want to discourage anyone from tackling this as at the very least it is a great computer science exercise and surely a learning experIEnce for anyone attempting it.If you continue with your port, you are going to have to face the realization that you will always be behind the Java version in terms of features and compatibility - unless you're able to implement the features every time you see a commit message.> For example, I know that portersteimmer is deprecated by snowball... > exist> other classes not worth to port now?If you don't plan on spending every waking moment porting, why not join forces with the SWIG Lucene folks and interface to that from Delphi?> Something else I must know? The code is based in Lucene 1.4.3...You're already behind and there has been dramatic changes with the latest codebase that will be Lucene 1.9/2.0.作者是：Erik ， lucene in action 的作者。作者的主要觀點是：1、最好利用類似PyLucene 的方式來實現lucene的多語言化。2、Lucene 1.9/2.0 將會發生重大變化。(我正在翻譯中)，多語言的lucenene 要麼很難在時間上和Java lucene保持兼容，要麼遷移到多語言的過程很辛苦。每個commit，你都需要跟蹤，然後修改......
