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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
