Re: unload JVM?

[Andi Vajda <va...@apache.org>]

On Feb 28, 2010, at 7:16, Roman Chyla <ro...@gmail.com> wrote:

>>> - consecutive calls to initVM raise errors
>>
>> Only if you use parameters other than classpath, right ?
>
> yes
>
>> Or did you find a different problem ?
>>
>>> - in my program components interact with several JCC wrapped  
>>> libraries
>>>
>>> Normally, it is no problem, but clashes may occur - especially in  
>>> GUI
>>> when running complex workflows - the solution (in theory) would be  
>>> to
>>> destroy JVM and load it again. Is it possible?
>>
>> In theory, it might be. The JNI API has a call to destroy a VM.
>> http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/invocation.html
>> But cleanly doing so it rather tricky so JCC doesn't support it.
>
> I tried (naive) to add destroyJavaVM call into the source, recompiled
> it and tried calling it from thread. The destroy call returns 0, but
> as soon as I delete references and object is garbage collected
> (probably), Python crashes. I have no idea what's going on :-)

You need to at least be sure that no python object is holding any  
references to java objects. This includes classes. All java object  
references held are stored and counted in a C++ map object sitting in  
the JCCEnv instance global to jcc at runtime. If this map is not empty  
before killing the vm bad things will happen. A way to clear this map  
is to get rid of all the python objects holding references into it  
(including classes).
There is a debugging method on JCCEnv that iterates this map (forgot  
the name, not near my computer).

> Browsing through the Sun bug reports, it seems like it wasn't possible
> (ie. DestroyJavaVM never worked, at least for others, who apparently
> understand what they were doing).

Yeah, not too surprised there.

> But if possible and one day it happens, cool, JCC is really blessing
> for connecting Python with Java and I imagine more people will start
> using it, and with more programmers using it, there will come more
> python packages in one installation...

Yep :-)

Andi..

>
> roman
>
>>
>> A different approach to supporting your use case might be to consider
>> compiling all your JCC wrapped libraries into one, picking only the  
>> APIs you
>> need so as control the size of the resulting library.
>>
>> Andi..
>>