Hi Andi >> Besides the fact that JCC could need a "--help" parameter, it all went >> very smoothly, I just ran into two small problems: > > Most of the command line flags are documented here > http://lucene.apache.org/pylucene/jcc/documentation/readme.html#use > A --help flag would be nice indeed. Would you like to contribute a patch ?
I'll see what i can do about that :-) [...] >> The way it is now, I really don't use more than 5% of iText's API and >> can't really tell if the wrapper contains all necessary external classes > > Two situations here: > 1. you're trying to generate wrappers for the 5% you're using: > get to know those 5% and be sure to have all you need either in what > these classes pull in or via --package or direct class listing > > 2. you're trying to generate wrappers for the entire API (like PyLucene): > same as above, get to know the entire API, and port all unit tests and > samples to python to test that you've got the coverage you need > (assuming the tests and samples have good coverage). It may also be > likely (as is the case with PyLucene) that you might have to provide > extension point classes when the Java API you're wrapping expects its > users to provide subclasses or interface implementations of their own. > (for example, PyLucene custom analyzers). 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 the moment the wrapper works perfectly for me, but I would like to make it available to the internet at large... I'll probably settle for a "website with building instructions, a release clearly marked 'alpha' and a rapid release cycle"-type of pet-project :-). >> to use iText properly. I'm a bit lost there and would welcome pointers and >> ideas on how to do this correctly. What happens if a Python program uses >> multiple JCC-wrapped JVMs, would the wrapped types "itext.FileOutputStream" >> and "lib2.FileOutputStream" collide? > > 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: > http://lucene.apache.org/pylucene/jcc/documentation/install.html#shared 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) [...] > Yes, this is a well known problem. JCC has a hardcoded list of words that > can lead to such unfortunate collisions. I need to add another command line > argument that makes it possible to add more such reserved words. Any use of > words in this list is mangled. > Currently, that list of words is in cpp.py, line 71: > > RESERVED = set(['delete', 'and', 'or', 'not', 'xor', 'union', 'NULL', > 'register', 'const', 'bool', 'operator']) > > JCC 2.2 does a much better job than earlier versions at this already. I saw your follow-up on the new "--reserved" functionality. This is much appreciated! cheers Jonas
