[Xapian-devel] Re: Xapian jni

[Olly Betts]

On Wed, Dec 27, 2006 at 04:17:57PM -0500, Eric B. Ridge wrote:
> Another thought is to ditch both Xapian_jni and SWIG for Java, and  
> instead implement a pure-Java xapian-tcp client.  I'm not familiar  
> with that side of Xapian, but that really seems the way to go for  
> good Java support.  Let xapian listen on localhost (or another box)  
> and Java can just communicate with it directly.  Something like this  
> would eliminate all of the above issues (and more!) and really fit  
> into the way Java likes to do things.

I suspect the remote backend overhead will be larger than the JNI
overhead.  You couldn't implement Java subclassing of C++ classes if you
used this technique either, and this is currently supported for at least
MatchDecider and ExpandDecider.

Plus you'd need to transparently allocate ports in a manner which
doesn't interfere with other processes on the box and manage permissions
on the tcp backend servers (so other processes can't intercept "your"
tcp backend before you manage to open it).  Unix domain sockets might be
a better approach, but that's no good on Microsoft Windows.  Or perhaps
named pipes, which I think Microsoft Windows does have an equivalent of.

Someone would need to port the remote client code to Java, and also be
willing to keep it up-to-date with changes to the C++ version.  The
current JNI bindings have lagged behind because of the amount of effort
required to update them compared to the SWIG bindings.  A major
motivation for moving Java to use SWIG is to reduce the effort required
to update it as the C++ API evolves (currently Java takes several times
as long to update as all the SWIG-using languages together).

> Alternatively, re-write Xapian in Java.  ;)

That would also increase the maintenance burden a tad.

Cheers,
    Olly