lucene-pylucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonas Maurus <jonas.mau...@gmail.com>
Subject JCC: wrapping iText / issues with standard library macros / suggestions
Date Mon, 06 Apr 2009 15:10:04 GMT
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

Mime
View raw message