Hello everbody,
seeing that last month had a thread on wrapping PDFBox, obviously
there's some demand for a fully-featured PDF library for Python :-).
So for one of my projects I started working on wrapping iText with JCC
today and I want to state that I'm really impressed! JCC rocks.
Besides the fact that JCC could need a "--help" parameter, it all went
very smoothly, I just ran into two small problems:
* I had to to some trial-and-error recompiling because JCC doesn't
include subtypes in the dependencies which means, for example, that
when you really should use a FileOutputStream, iText usually only
imports a OutputStream (probably a calculated dependency from the
libraries method signatures), so it needs some fiddling with --package
to get all necessary classes in.
Is there a good way for forcing the import of a whole package? 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 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?
I also haven't started to identify any iterables or sequences that can
be made "pythonic", using JCC's built-in extensions. Is there a good
way to grep for those?
* when compiling the extension, JCC generated the following code:
namespace com {
namespace lowagie {
namespace text {
namespace pdf {
[...]
static PdfName *DOMAIN;
[...]
which led to this error:
build/_itext/com/lowagie/text/pdf/PdfName.h:173: error: expected ';'
before numeric constant
This happens, because "DOMAIN", unfortunately, collides with the macro
#define DOMAIN 1
in <math.h>.
I fixed this error by adding:
[...]
#define _OLDDOMVAL_ DOMAIN
#undef DOMAIN
static PdfName *DOMAIN;
#define DOMAIN _OLDDOMVAL_
[...]
and that allows everything to compile, but it's a hack. Currently I
think that to make JCC a real general-purpose tool that can wrap 99.9%
of all libraries out-of-the-box, it will need to do some name
mangling. Has anyone on the list developed a good solution or
work-around for these situations?
BTW, my current process for building is:
1. python -m jcc --jar iText-2.1.5.jar --include bcprov-jdk16-142.jar
--include junit4.5/junit-4.5.jar --package java.io
java.io.FileOutputStream java.io.FileInputStream --package java.util
--python itext --version 2.1.5 --build
... wait for it to fail, then edit PdfName.h like described above
2. python -m jcc --jar iText-2.1.5.jar --include bcprov-jdk16-142.jar
--include junit4.5/junit-4.5.jar --package java.io
java.io.FileOutputStream java.io.FileInputStream --package java.util
--python itext --version 2.1.5 --compile
3. python -m jcc --jar iText-2.1.5.jar --include bcprov-jdk16-142.jar
--include junit4.5/junit-4.5.jar --package java.io
java.io.FileOutputStream java.io.FileInputStream --package java.util
--python itext --version 2.1.5 --bdist
4. easy_install dist/itext-2.1.5-pyXYZ.egg
I'm pretty certain that all of the above leaves a wide room for
improvement :-). So thanks in advance for any comments.
Best regards from Germany,
Jonas
