[Fwd: [Java-gnome-developer] Java-Gnome, ARM processors and gcj]

[Mark Wielaard <mark at klomp dot org>]

Hi all,

These kind of things make me all excited about what we are doing!
I just had to share it with all of you. Go gcj developers! Go java-gnome
developers! I don't have a iPaq, but if this works as described then I
will certainly but it on my wish list.

Cheers,

Mark

--- Begin Message ---

• From: Bob Fischer <bob dot fischer17 at earthlink dot net>
• To: java-gnome <java-gnome-developer at lists dot sourceforge dot net>
• Date: Wed, 25 Feb 2004 21:48:19 -0500
• Subject: [Java-gnome-developer] Java-Gnome, ARM processors and gcj
• References: <1077743066.6186.53.camel@ibook>

Following is my experience compiling Java-GNOME for the ARM processor
using a gcj cross compiler.  It was not easy, but in the end things
work.  I hope this document will help improve future versions.

I wanted to build Java programs with GUIs on a GNU/Linux iPaq. 
Surprisingly, there are not many options.  For one, the regular Java
system won't fit on the iPaq's 32Mb flash memory.  I ended up using GCJ,
the GNU native code Java compiler, at a space cost of about 7 Mb for the
runtime libraries.

On my x86_64 desktop machine, I built a gcj cross compiler toolchain.  I
used gcc-3.2.3 and glibc-2.3.2.  I used java-gnome 0.8.2.  This was not
the newest Java-Gnome at the time; however, it fit the version of GTK+
included on the iPaq Familiar 0.7.2 distribution (GTK+-2.2.4).

No Gnome on iPaq!!!
===================

The first big problem I had was that Java-Gnome assumes it is being
built for a full-fledged desktop environment.  Since this is the iPaq,
GTK+ and Glade are the only parts of the GTK suite that make sense. 
Gnome, Vte and Gconf are not part of Familiar, and I did not have
libraries or headers for them.  Therefore, I had to hack various
Makefile.in.in files to compile and install ONLY Java-gtk and
Java-glade.  I also had to change src-Makefile.in.common to avoid
linking to the GTKHTML and GNOME libraries on the command lines.

The Java-Gnome tutorial assumes Gnome.  I had to guess a little bit to
come up with a demonstration Java-GTK+ program that did not use Gnome. 
This is my first experience with GTK+, so it was a pity that the demo
programs were useless.

GCJ JNI Problems!!!
===================

Java JNI, used by Java-Gnome, requires dynamic library capabilities
(System.loadLibrary()).  Under normal circumstances, that functionality
is disabled in GCJ when being built as a cross compiler.  I tried to
turn it on, but ran into a bug in GCJ (that's another story, one for the
GCC e-mail lists).  Finally, I settled on building my GCJ cross compiler
to pretend to have it turned on, but actually do a NOP when asked to
load a library dynamically.

This begs the question of how to use JNI in my Java-GTK programs.  I did
three things to make this work:

 1. I built my GCJ cross-compiler toolchain with the NOP loadLibrary()
in place.  This is important, even though there is no actual dynamic
library loading capability; otherwise, attempts to use JNI end up with a
Java exception, even though the system does not need to load any dynamic
libraries.

 2. By default, Java-GTK compiled with GCJ produces two libraries: one
of the JNI bindings, and one of the Java code.  I put them both in one
library instead; therefore, libgtkjar0.8.so contains BOTH the JNI
bindings AND the Java code.  This library is linked in by the loader
because it is required for the Java part of the Java-Gnome calls.  So
the JNI bindings are already there when needed.

 3. System.loadLibrary() is called in static initialization code in the
Java-Gnome libraries; for example, Gtk.java.in contains the lines:
    static {
        System.loadLibrary("gtkjava@apiversion@");
    }
 I commented out the System.loadLibrary() line.  Unfortunately, this
results in a version of Java-Gnome that is no longer standard Java; I
had to change the Java code due to GCJ bugs described above.

The resulting system actually works when loaded on the iPaq; I could
make sample GTK+ programs in Java!  However, it is sobering to realize
that the Java-GTK bindings are ALMOST TWICE AS BIG as the original
libgtk-x11 library:
    2977048 libgtkjar0.8.so.0.8.2
    1690200 libgtk-x11-2.0.so.0.200.4

Conclusion
==========

Action points from this article:

 1. It would be nice to be able to easily select which parts of
Java-Gnome one wishes to configure and install.  I believe this is
already in newer versions of Java-Gnome.

 2. It would be nice if JNI on cross-compiler GCJs just worked in the
future.  However, we cannot count on that for now.  In the meantime,
there should be a special option for Java-Gnome + GCJ.  This would
include:
 a) Linking the JNI code and Java classes into the same .so library.
 b) Removing calls to System.loadLibrary() from the static initializers.

 3. One might consider building CNI bindings for the GTK+ calls, rather
than the current JNI bindings.  These would certainly be smaller and
more efficient when using GCJ.  CNI bindings could also sidestep the
dynamic library loading problems I experienced (although I sidestepped
them without CNI).  However, the added work of keeping two sets of
bindings up to date might not be worth it.

For anyone who is interested, I can share more details regarding the
modifications I made to the system in order to get it to compile.  I am
still impressed that it worked as easily it did, given that more likely
than not neither ARM processors nor iPaqs nor gcj nor cross compilers
were in mind when building Java-Gnome.

Sincerely,
-- Bob




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
java-gnome-developer mailing list
java-gnome-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

--- End Message ---

Attachment: signature.asc
Description: This is a digitally signed message part