Re: Dynamic loading - solutions and more problems

[Bryce McKinlay <bryce at albatross dot co dot nz>]

Matt Welsh wrote:

> Your new example doesn't work for me. Neither does the following: if I
> have "ToLoad" implement an interface ("ToLoadIF") and then have in
> MainProgram.java:
>
>       Class ToLoadCls = Class.forName("ToLoad2");
>       ToLoadIF toload;
>       toload = (ToLoadIF)ToLoadCls.newInstance();
>       toload.doit();
>
> We get the same failure in loading MainProgram.so, ostensibly because
> "ToLoadIF" is being referenced by MainProgram.so, and the loader doesn't
> like undefined references.

Huh? Why is ToLoadIF undefined? Link it into MainProgram.so and
everything should work fine. It works for me with either MainProgram and
ToLoadIF in MainProgram.so, ToLoadExt in ToLoadExt.so, or MainProgram
and ToLoadIF in MainProgram.so and ToLoadExt in a .class file. It
doesn't work with MainProgram and `ToLoadIF in .class files and
ToLoeadExt in an .so, but thats a separate issue I think.

Basically, the rule here is currently this: If you reference a class
directly, you must link it the normal way (either statically or by the
platforms native dynamic linking mechanism). Anything more than this is
a design issue rather than a bug. I'm not arguing whether or not the
ability to do this would be useful, but that the loading mechanism was
not designed to support such things.

> allowing gij to load it won't work if that class accesses *anything
> outside of the classes defined in libgcj). Using -fno-assume-compiled 
> does not solve the problem because of the bug in
> PrepareCompiledClasses().

Just to be clear: There is no bug in _Jv_PrepareCompiledClasses() here.
InitializeClass() is being called on a totally invalid class reference,
and it just happens to get this far before crashing.

regards

  [ bryce ]