Ed, I hear ya. I struggled with that decision. I agree that logically, a finalizer (the Java term for destructor) makes a lot of sense, especially since some (many? most?) implementations won't even worry about doing any explicit clean-up. My reasoning hinged on two important points: 1) the initial (and still current) SGE implementation did require clean-up, and 2) finalizers are generally a bad idea. Finalizers in Java screw up garbage collection because they end up taking two or more gc's before they actually get collected. (The first gc calls the finalize() method, and assuming finalize() didn't make matters worse, the next gc actually collects the object.) Because the DRMAA specs tend towards inclusivity, the fact that the operation is in the DRMAA 1.0 spec and the SGE implementation would need, is enough to require it in the spec. (Another issue that has come up since the spec was initially written is how to do a remotable Session interface to a DRMAA library with native code. It that case, it becomes quite a bit easier to simply know that your clients will tell you explicitly when they're done with their job templates.) In the case of a pure Java implementation with no funny tricks, the deleteJobTemplate() method ends up being essentially empty. I hold that it is within the rights of such an implementation to provide a deleteJobTemplate() method, but to declare the use of the method unnecessary. Such a statement would, of course, carry the caveat of producing code that is not strictly portable, much like the optional and implementation-defined job template properties. Daniel Ed Baskerville wrote:

Hi again,

I'm putting together headers for the Xgrid Objective-C DRMAA interface, and ran into another question for you on Java DRMAA: why do you include a deleteJobTemplate method in the Session interface? As far as I can tell, a JobTemplate is basically just a data structure, so why can't releasing the C struct just get taken care of in the destructor?

My instinct with ObjC is to just put it in the analogous "dealloc" method rather than having an explicit deleteJobTemplate: method in DRMAASession. (In my case, there's not even any C struct to free, since Objective-C is the native implementation for XgridDRMAA.)

--Ed