Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Patch for JObject shutdown annoyance

Ken Melms
2008-11-19
2013-04-29
  • 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.

      K

       
      • 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.