Re: [java-gnome-hackers] --with-gcj-compile

[Tom B. <Tom...@Su...>]

Hi Istvan,

I'm not a team leader, but may be able to address some of these
problems.  You unfortunately grabbed a snapshot of our project when it
is in the midst of a massive API overhaul -- we hope to have things
cleaned up soon for a '0.8' release soon, but aren't there yet.  While
we appreciate all the feedback, you may want to join our "announce"
mailing list and wait until that event to minimize your frustration.

On Wed, 2002-12-04 at 09:55, VEROK Istvan wrote:
> The --extdirs is needed because I killed two birds with one stone:
> I have JDK 1.4.1 in /opt/jdk, and (on one hand) the Glade bindings
> want JAXP (understandable), and (on the other hand) the SignalHandler
> class wants to be a subclass of InvocationHandler, which is a Java
> 1.3 dependency (only satisfiable by /opt/jdk/jre/lib/rt.jar) introduced
> quite recently by Tom Ball.  No flames, just an honest question:
> was this really necessary?  I mean, from the free software angle.

I'm a big supporter of open software, but not obsolete software.  While
gcj doesn't support Proxy (InvocationHandler is just an interface), it
will have to soon or risk splitting the Java platform.  I suppose I
could write something similar, but it would be very difficult as there's
a lot of good work in the proxy support classes.

If you know of a cleaner way to dynamically tie a method to a widget
using the org.gnu.gtk.event Listener interfaces, I'd love to hear it. 
I'm not tied to using dynamic proxies; it's just that we're using them
for exactly what they were designed to do.  Being lazy (one attribute of
a good programmer), I would rather use what exists than recreate it.

BTW, I'm rewriting the glade file parser to not use JAXP or SAX, so our
stuff won't have as many external dependencies. 

> Then I discovered that I needed to edit build.xml's build-glade
> target to say

> <include name="org/gnu/glade/**"/>
>                             ^^^
> 
> because the resulting glade.jar contained practically nothing
> otherwise (I'm using Ant 1.5).  A recompile followed.

Already fixed and checked in; you unfortunately caught a one-day window
where that was broken.

> I have yet to get native compilation working.  I can get class files
> using Java-GNOME, but my efforts to compile, say,
> src/examples/glade/Examples1.java into a native binary have so
> far all failed with hundreds of linking errors like
> 
> ../lib/libGTKJar.so: undefined reference to 
> `org::gnu::gtk::SpinButton::gtk_spin_button_get_adjustment(int)'

It sounds like our Java classes can't access their associated native
methods when compiled natively.  That's either a bug in our build (most
likely) or a gcj bug.  Please file a bug so we'll fix this.  Right now,
my understanding is that native compilation is a lower priority than
just getting things working again after all the recent design changes.

Tom