Dynamic class loading

[Matt Welsh]

Thanks for the quick response, Tom.

> The latest HEAD libgcj supports this.  You can build this libgcj with
> either the latest gcc (unstable) or with gcc 2.95.2 if you grab
> Bryce's gcj update patches (you'll have to search the list archives
> since I don't have the URL handy).

As I mentioned in my other message, the newest libgcj doesn't compile
with gcc 2.95.2 (darn). I'm building the latest CVS egcs right now. Do I 
still need to apply Bryce's patch?

> First we try to load a .so.  Then we try to find the .class file for
> the interpreter.  This choice was fairly arbitrary.

That's what I figured - just wanted to get that documented. Maybe it's
time for someone (me?) to take a crack at a GCJ-HOWTO :-)

> Would searching CLASSPATH get right answers enough?  I'd expect
> CLASSPATH to hold mostly architecture-independent paths (on systems
> where people make this distinction -- anyway maybe we shouldn't
> encourage people to conflate the two).

Not sure - that's why I suggested we have a GCJ_CLASSPATH which overrides
that decision.

libltdl lets one specify a "user search path" which we could easily plug
with the appropriate value.

First I'll get it working and then think about the right way to do this.
It might be that what's in there now is perfectly fine; however, I have 
a large project based on GCJ and would like to make this aspect of it 
as seamless as possible (to help people migrating off of a traditional
JVM).

One cute hack would be to have the "interpreter" fork off an instance of
gcj to quietly compile a .class into a .so in the background, and load it
right from /tmp - so that someone with an existing set of .class files 
doesn't even know gcj is there :-)

Cheers -
Matt