[Xapian-discuss] Xapian JNI questions

[Eric B. Ridge]

On Dec 6, 2006, at 9:47 PM, Olly Betts wrote:
> I vaguelly recall that Eric Ridge (who wrote the JNI bindings  
> originally) once said something about problems with finalisers getting
> called, but I can't find the mail.

Hi!

Yeah, one pretty serious problem with the Xapian JNI bindings is that  
the C++ destructors are at the mercy of Java's garbage collector.

> I think he said there's a Java API call which addresses this  
> problem, but that the Sun documentation says it's buggy
> and should be avoided or something like that.  Without the mail  
> it's hard to be sure I'm not misremembering though.

There is:  java.lang.System.runFinalizersOnExit(true);

and Sun does say that "This method is inherently unsafe.":
	http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ 
System.html#runFinalizersOnExit(boolean)


>> 2)  finalize method must be called  on any Xapian JNI onject when its
>> no longer needed ?
>
> Currently at least, it shouldn't really matter for anything except
> WritableDatabase.

Yes, and you'll need to explicitly call the .finalize() function if  
you want Quartz' underlying lock file to be cleaned up.

It might make sense to add a .close() function to WritableDatabase,  
but I was trying to mirror the C++ class as closely as possible.

>> With this change the NoSuchMethodError exception is no longer thrown,
>> however, it looks like the JavaMatchDecider is not called at all.
>
> If you want to just use a MatchDecider, you need to subclass it and  
> pass an
> instance of your subclass to get_mset() like this (this is a pointless
> matchdecider which rejects everything):

That's the correct usage.

> Looking at the code, I think it's trying to find the constructor for
> org.xapian.Document as "<init> (J)".  Is that the right thing to look
> for?

That's right, and that ctor is package-private.  It needs to be  
public for JNI-side to find it:
	public Document (long id) { ... }

I never tested the C++ side of the wrapper that calls back into the  
Java-based MatchDecider implementation was never tested, so I'm  
unsurprised that there's a small bug here.

eric