diff options
Diffstat (limited to 'ubuntu/maverick_automake/kdebindings/debian/libqt3-java-kde3.README.Debian')
| -rw-r--r-- | ubuntu/maverick_automake/kdebindings/debian/libqt3-java-kde3.README.Debian | 64 |
1 files changed, 0 insertions, 64 deletions
diff --git a/ubuntu/maverick_automake/kdebindings/debian/libqt3-java-kde3.README.Debian b/ubuntu/maverick_automake/kdebindings/debian/libqt3-java-kde3.README.Debian deleted file mode 100644 index ea0beb81c..000000000 --- a/ubuntu/maverick_automake/kdebindings/debian/libqt3-java-kde3.README.Debian +++ /dev/null @@ -1,64 +0,0 @@ -Developing and using Qt based applications written in Java -========================================================== - -This document explains how to develop and use Qt based programs -written in Java. This is what the Qt java bindings from the package -libqt3-java are designed to accomplish. - -Firstly, the bindings should work with any java compiler and VM -properly implementing the JNI interface, but they have only been -tested with the GCJ compiler and GIJ interpreter from the GCC suite. -Note that the bindings are not compiled to native code, using GCJ's -unique capability to do this, they are simply compiled to .class -files, and interpreted, in the classical Java manner. - -Secondly, when compiling and running apps using the Qt Java bindings, -you need to add "/usr/share/java/qtjava.jar" to the CLASSPATH. E.g. - - export CLASSPATH="/usr/share/java/qtjava.jar:/usr/share/java:." - javac Whatever.java - java Whatever - -And, that's basically the hard part of it all. For the rest, -developing Qt Java apps is much like Qt C++ apps, except that working -with slots is easier, and compiles may be faster as well. The API -should be completely similar to the Qt C++ API, so the standard Qt -docs should translate pretty easily. There are a lot of Qt Java usage -examples in /usr/share/doc/libqt3-java/examples. - -If you're interested in developing KDE applications using Java, look -at the libkde3-java package. - - -Generating native executables ------------------------------ - -It is also possible to produce native executables with the following gcj -invocation: - - export CLASSPATH="/usr/share/java/qtjava.jar:/usr/share/java:." - gcj -fjni Somefile.java /usr/share/java/qtjava.jar --main=Somefile - LD_LIBRARY_PATH=/usr/lib/jni ./a.out - -As this will compile the full qtjava.jar into native code, the resulting -executable will be rather large. If you plan on having several of these -executables, it may be worth creating a shared qtjava library, like -this: - - gcj -fjni -shared /usr/share/java/qtjava.jar -o libqtjava-shared.so - -And then, after you put libqtjava-shared.so in /usr/lib or similar, you -can go like: - - gcj -fjni Somefile.java --main=Somefile -lqtjava-shared - LD_LIBRARY_PATH=/usr/lib/jni ./a.out - -In the future, I'll investigate the possibility of shipping the -qtjava-shared library in the Debian packages. - -Also, in order to avoid the necessity of setting the LD_LIBRARY_PATH -environment variable, the option -Djava.library.path=/usr/lib/jni can be -passed to the gcj invocation. There is, however, a bug [1] in gcj that -prevents this from working, and it's only fixed in gcj-4.0. - - [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18234 |