RE: [Java-gnome-developer] How to make Java-Gnome popular...

[Jeffrey M. <Jef...@Br...>]

I would recommend stripping the shared objects.  This will
reduce the size by a significant amount.  On my system you
this reduces them to a very acceptable size.  The following
lines are the output from the size command on my system
without any modifications to the build after stripping the 
shared objects:

   text    data     bss     dec     hex filename
 402270  195912    3044  601226   92c8a libGNOMEJar.so
 178073    2912      28  181013   2c315 libGNOMEJava.so
1607282  809348   14132 2430762  25172a libGTKJar.so
 574135    8960      52  583147   8e5eb libGTKJava.so

The physical size of the shared objects are:

 601020  - libGNOMEJar.so
 183800  - libGNOMEJava.so
2424700  - libGTKJar.so
 591056  - libGTKJava.so

After recompiling with the -O3 options I yield the following
results:

   text    data     bss     dec     hex filename
 402312  190292    3044  595648   916c0 libGNOMEJar.so
 180801    2908      28  183737   2cdb9 libGNOMEJava.so
1612971  805828   14132 2432931  251fa3 libGTKJar.so
 584479    8956      52  593487   90e4f libGTKJava.so

 595432  - libGNOMEJar.so
 186516  - libGNOMEJava.so
2426876  - libGTKJar.so
 601420  - libGTKJava.so

As you can see, the -O3 options actually increases the size
of a few of the files.  This is due to the fact that O3 is
optimizing for speed and not size.

-Jeff

> Hi everybody!
> 
> I've now written a very first Version of my 
> wine-configurationprogramm 
> using gcj and java-gnome.
> There are two problems contributing my app:
> 
> 1. Java-GTK is very big!(~5megs (the java-jar, the gcj-so and 
> the c-part 
> of the bindings)
> I think this problem isnt so easy to solve. But ist a little 
> problematic 
> that the java-bindings are much bigger than the library for which the 
> bindings were written, maybe we can optimeze the code a 
> little bit, so 
> that we can use the -O3 flag for the C-part. -O2 should work 
> everywhere 
> and the  size of libjavagtk.so should decrease 30-50%. Are there any 
> optimisations used for now? I thin only the C-part is the 
> problem, the 
> jar-archive already very small. The second problem is the 
> compiled part 
> for the gcj, which is about ~3.2 megs big. maybe with some 
> playarounds 
> it can be done with 2.5megs but not less ;-(
> 
> 2. There are no user-ready packages avaible. (.deb, .rpm, .tar.gz)
> Althougt this is a big problem it  should be very easy to solve. Were 
> included in no distribution, and users cat even download any 
> binary-packages.
> I'll build some packages using esp in the next month - maybe we'll be 
> included  in UnitedLinux ;-)