Andrew Haley schrieb:
Felix Schwarz wrote:
> So I think JCC is basically the right thing to do as this is the only
> way you can always use the latest Python features (even Python packages
> that are written in C) and the latest Java (GCJ always had threading
> issues and is generally hard to debug).
I'm not going to let this one past. gcj does not have "threading issues",
whatever that means, and I don't agree that it's hard to debug. The latter
is a matter of opinion, but the former a matter of fact.
You are correct that threading inside of gcj was seemingly not that bad. I
should be more precise in my wording because these "threading issues" were
related to Python's threading - with a gcj compiled Lucene you had to be quite
careful what Python threading implementation you use (something that caused
some problems with CherryPy/TurboGears).
>> Specifically, "If the JNI-using code calls
System.loadLibrary you'll
>> have to patch it to use System.load, passing it the full path to the
>> dynamic shared object."
>>
>> For an example of this see
>>
http://cvs.fedoraproject.org/viewcvs/devel/javasqlite/
> Sorry, my wording was not detailed enough. JCC does "JNI the other way
> round" so it calls Java from C++. Therefore there is no
> System.loadLibrary which could be patched. Instead I have to rely on the
> standard linker configuration (or use rpath).
Or use a full path in dlopen().
I may be wrong but it seems that JCC does do any dlopens. Instead the code
is just linked against the Java libraries. I may be wrong on this, though.
What libraries does JCC need to open? Just libjvm, or others?
libjava.so and libjvm.so.
fs