Re: Why interpret dynamically loaded classes?

[Matt Welsh <mdw at cs dot berkeley dot edu>]

Jack Andrews <jack.andrews@str.com.au> writes:
> >  But why not just compile the dynamically loaded class to a
> >  > > native shared object at *runtime*, then link at runtime, too?
> >  > 
> > Perhaps, but I really like this idea.  I've been thinking of doing
> > this for a while but I've never found the spare time to try it.  I
> > don't think it would be very difficult.

I spent a significant amount of time working on this a few months ago,
and ran into some pretty serious limitations in gcc/gcj which prevented
me from making much progress. These things could probably be fixed but I
didn't want to put that much effort into it.

The core issue was that at the time I was working on this (in April), 
newer versions of GCJ and GIJ were very buggy, and would not properly
load precompiled .so files. I had to use newer versions of GCJ in order
to get the .so loading feature, but I ran into so many bugs that it
became infeasible. Hopefully these problems are fixed now, but I haven't
worked on GCJ since then.

One issue to look out for is that you need to be concerned about class
dependencies. Let's say that you have a class, A, which you wish
to load. First you want to compile A.class into a .so. However you also 
need to be concerned about any classes which A.class depends on -- since 
you need to prelink them against A.so. So if A.class depends on B.class 
and C.class, you need to be sure to prelink A.so with B.so and C.so, 
which might also need to be compiled. So you have to do a recursive
dependency check (and recursive class compilation) in order for this to
work. Circular dependencies can also arise. Dependencies themselves are
not too problematic, and 'gcj -M' can help, but it's still something to
think about.

Matt Welsh, UC Berkeley