libgcj problem in FindClass with shared libraries.

[Andrew Haley]

abhishek desai wrote:
> _Jv_RegisterClasses is called but only initially. Not after we call
> FindClass.

Right, which is the cause of your problem.  You need to find out why
_Jv_RegisterClasses is called by libgcj but not by the shared library
that you created.

> Also there is no call happening to dlsym after the library
> is opened using dlopen in libdl. How are the symbols loaded then ?

You don't need it.  _Jv_RegisterClasses updates the cache in the class
loader that is queried to find the class.

Andrew.


> On Wed, Jun 3, 2009 at 3:42 PM, Andrew Haley <aph@redhat.com> wrote:
>> abhishek desai wrote:
>>
>>> I am using libgcj version 3.4.6 (I have to use this version of gcc and
>>> libgcj) .
>> Well, we can't fix it.  It is ancient history.
>>
>>> I have shared libraries with precompiled java clases and am
>>> using JNI function call "(*env)->FindClass" to get the class. Tracing
>>> through the _Jv_JNI_FIndClass I found that the dynamic library gets
>>> loaded but the symbols are not loaded into the cache.
>>>
>>> In the function call "jclass
>>> gnu::gcj::runtime::VMClassLoader::findClass (jstring name)"
>>> there is a call to "jboolean java::lang::Runtime::loadLibraryInternal
>>> (jstring lib)" . This does the loading of the library by eventually
>>> calling dlopen in libtdl.
>>>
>>> After this call there is no call to access the symbol from the library
>>> or to load it to the cache.
>>> But the symbol is searched for in the cache using _Jv_FindClassInCache
>>> which returns NULL. Is this a bug or I am missing something ? Need
>>> help with getting the symbols loaded.
>> You need to make sure that _Jv_RegisterClasses is being called when the
>> shared library is loaded.  If it is, then the classes in the library will
>> be found; if not, then you need to find out why not.
>>
>> Put a breakpoint on _Jv_RegisterClasses.  You should see it called once
>> at startup, again when libgcj.so is loaded, and each time a shared library
>> is loaded.
>>
>> Andrew.
>>
>>