[Xapian-devel] Re: Xapian jni

[Eric B. Ridge]

On Dec 27, 2006, at 8:19 PM, Olly Betts wrote:

> I suspect the remote backend overhead will be larger than the JNI
> overhead.

You're probably right, but the tradeoff might be worth it to  
eliminate all the headaches that come with JNI.  Most Java folks I  
know, myself included, really hate dealing with JNI'd libraries  
because of the platform dependence issues they create in addition to  
possible fragility.  Generally the JVM doesn't crash -- loading JNI  
libs increases the chances tremendously.

> 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.

Now that's true, but one could argue that it'd be acceptable to  
implement these in C++.  I haven't given it much thought but maybe  
there'd be a way to extend the wire protocol to support client-side  
Match/ExpandDeciders?

> 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).

I dunno about all that.  I think in this scenario you'd have to think  
of Xapian as a remote database backend a la MySQL or Postgres.  Maybe  
the Xapian backend would need a master server listener that would  
fork the client to use the backend database it requested.  This  
probably means an entirely new wire protocol and backend  
infrastructure, but it might be worth considering from a client- 
accessibility point of view.

> 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.

Well there is that!  By no means am I volunteering.  :(  I'm part of  
the current Java bindings problem rather than the solution.  I was  
just trying to suggest something that might provide additional  
benefits for Xapian in general (and all "bindings") rather than only  
for Java.

> 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).

Refresh my memory... what's the hold-up for just switching to SWIG?

>> Alternatively, re-write Xapian in Java.  ;)
>
> That would also increase the maintenance burden a tad.

I meant to also add "with a BSD license".  And about 5 more smilies!

eric

ps, thanks for keeping me cc'd... I'm not subscribed to the -devel list.