lucene-pylucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <>
Subject Re: JCC: wrapping iText / issues with standard library macros / suggestions
Date Tue, 07 Apr 2009 17:28:31 GMT

  Hi Jonas,

> I didn't get my hopes up anyway for an easier way to do this than
> "just learn everything there is to the API you're trying to wrap". For

Consider that before JCC, PyLucene, for which JCC was originally written, 
had its wrappers written by hand. Tens of thousands of lines of boilerplate 
C++ code. And before being handwritten, SWIG was used instead. 'Easier' is a 
matter of perspective :)

>> A given process may embed only one JavaVM. If you want to use multiple
>> JCC-built extensions in the same process be sure to use shared mode:
> Yes, I do. I installed the patch for setuptools and created a
> shared-mode library. In this case, would the two "FileOutputStream"
> wrappers be recognized as the same type by two libraries hosted in the
> same JVM? (the question is probably stupid, but I don't know a lot
> about JCC, yet)

The Python types for FileOutputStream would be different. One from module 
'a' and another one from module 'b'. The Java classes for FileOutputStream 
would be the same provided they came from the same class loader. This is an 
oversimplification of course as class loaders can behave in subtle ways.

When a Python instance of a wrapper is passed to Java, it is unwrapped, only 
the Java instance is actually used.

If, inspite of the expected simplicity of this premise (note the careful 
wording here :) problems were to arise in sharing objects between different 
JCC-built Python extensions, they could be worked around by simply 
generating a new extension that is the union of both. This also has the 
advantage that this union is smaller than the sum since the intersection 
would not be wrapped twice (only one wrapper for FileOutputStream, for 

I say 'simply' here because, if the JCC invocations for building both 
extensions are known, you're a compile away of generating the union.

Then, you may also hit bugs since this --shared method is rather 
infrequently used to its full extent. I've been using this to implement Java 
servlets in Python under Tomcat (sort of a reverse embedding). Shared 
mode there is essential and represents, probably, the most extensive use of 
it that I'm aware of.


View raw message