This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Dynamic class loading



Hi Bryce et. al., 

Thanks for updating the NEWS file. I have a couple of questions:

> +* Runtime.loadLibrary() has been implemented. In addition, Class.forName() 
> +will try to load a series of shared objects in order to find the requested 
> +class.  If a class `gnu.quux.whatever' is requested, libgcj will first look 
> +for `gnu-quux-whatever.so', then `gnu-quux.so', and finally `gnu.so'.

Great! This is the feature I have been waiting for! What version of gcj 
supports it? Since I'm hesitant to run a less stable gcj/libgcj snapshot, 
I'd like to know if there are any plans for labelling a version with 
this feature as "stable" (as libgcj 2.95.2 was).

Also, this description is a little confusing. First you say that if a class
can't be found, the interpreter will be used, but now you're saying that 
a shared object will be searched for first. Maybe we should unify the 
description of the interpreter and the shared-library search mechanism.

Also, where are the .so's searched for? Only the current directory? Or
on LD_LIBRARY_PATH? It might make sense for CLASSPATH to be searched first,
or perhaps something like GCJ_CLASSPATH. 

I would argue that the mechanism for searching for .so files should be as
close as possible to the mechanism for searching for .class files. However,
I like the idea of wrapping up a whole package into a single .so.

Cheers -
Matt


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]