Dynamic class loading

Sat Apr 1 00:00:00 GMT 2000

Matt> Great! This is the feature I have been waiting for! What version
Matt> of gcj supports it?
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).
Matt> Since I'm hesitant to run a less stable gcj/libgcj snapshot, I'd
Matt> like to know if there are any plans for labelling a version with
Matt> this feature as "stable" (as libgcj 2.95.2 was).
Currently we don't have a plan for this, because the new libgcj relies
on changes to the compiler -- and re-releasing a subdir of the
compiler seems a bit bogus.
I haven't heard anything about the gcc release plans. I don't even
know what the gating factors are there.
I agree this isn't the best situation.
Matt> Also, this description is a little confusing. First you say that
Matt> if a class can't be found, the interpreter will be used, but now
Matt> you're saying that a shared object will be searched for
Matt> first. Maybe we should unify the description of the interpreter
Matt> and the shared-library search mechanism.
First we try to load a .so. Then we try to find the .class file for
the interpreter. This choice was fairly arbitrary.
Matt> Also, where are the .so's searched for? Only the current
Matt> directory? Or on LD_LIBRARY_PATH? It might make sense for
Matt> CLASSPATH to be searched first, or perhaps something like
Matt> GCJ_CLASSPATH.
We use libltdl to load libraries.
So we search the libltdl path (LTDL_LIBRARY_PATH) followed by the
system search path (eg LD_LIBRARY_PATH, but this depends on the
system).
We could add another variable fairly easily.
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).
Tom