Patch for JObject shutdown annoyance

Ken Melms
  • Ken Melms

    Ken Melms - 2008-11-19

    JObject emits a message on application shutdown for each JACEified class in use on program termination.  This isn't precisely an error if JACE has been shutdown already.  I propose we stifle the warning if JNIHelper's shutdown() was already called.

    Patch below:

    --- source/c++/source/jace/proxy/JObject.cpp    2008-11-19 13:15:29.000000000 -0500
    +++ source/c++/source/jace/proxy/JObject_new.cpp    2008-11-19 13:16:59.000000000 -0500
    @@ -109,8 +109,11 @@
       catch ( exception& e ) {
    -    cout << "JObject::~JObject - Unable to delete the global ref." << endl;
    -    cout << e.what() << endl;
    +    if (!helper::hasShutdown())
    +    {
    +      cout << "JObject::~JObject - Unable to delete the global ref." << endl;
    +      cout << e.what() << endl;
    +    }

    • Gili Tzabari

      Gili Tzabari - 2008-11-20

      I'm just curious, where are you calling shutdown() from? If you are invoking it after DestroyJavaVM as the documentation indicates you should never be getting this warning.

    • Ken Melms

      Ken Melms - 2008-11-21

      I tried before and after, got those messages both ways.. I'll double check.

      I was thinking though ..

      Should we really have to reach in to the VM Environment and call DestroyJavaVM before calling shutdown?  It's the only time I need to touch the ENV at all, and seems like something that shutdown() should be doing for us.


      • Gili Tzabari

        Gili Tzabari - 2008-11-22

        That's actually not a bad idea. There are all sort of limitations for calling DestroyJavaVM though so I'll have to investigate the impact of making this change.

        I'll let you know once a new version is out for you to take a look at.

      • Gili Tzabari

        Gili Tzabari - 2008-11-27

        I believe this is the way it works:

        1) VmLoader::loadVm() loads jvm.dll/so if needed
        2) VmLoader::createJavaVM() creates the JVM
        3) You interact with the JVM
        4) VmLoader::destroyJavaVM() destroys the JVM -- this method doesn't yet exist
        5) JNIHelper::shutdown() invokes VmLoader::unloadVm()
        6) The reason JObject's destructor is giving you warnings on shutdown is because you're shutting down the JVM before destroying your proxies. You need to explicitly destroy them beforehand. If you have stack-scoped variables you need to make sure their destructors fire before you shut down.

        I'm thinking of removing JNIHelper::shutdown(), adding VmLoader::destroyJavaVM() and telling users to invoke unloadVm(). This way the load/unload calls will at least be symmetric.


Log in to post a comment.