关于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，你都需要跟踪，然后修改......