[drmaa-wg] Re: Java DRMAA: why deleteJobTemplate()

[Ed Baskerville]

I have basically two goals with the Cocoa interface: make it possible  
to wrap a DRMAA-compliant C interface around it (i.e., pass the  
tests); and give it a very Cocoa-like interface. Cocoa programmers  
(such as myself) tend to be obsessively committed to doing things  
"the Cocoa way": after all, if we wanted to use the C interface  
directly, we could, since Objective-C is a superset of C.

I don't really see the need to be IDL-compliant unless there's a  
strong desire out there for this. I think Cocoa programmers would be  
happier using something that's Cocoa-like than something that maps  
perfectly onto the C and Java interfaces. I suspect nobody else out  
there (except hopefully Apple, starting from my work) will be  
creating an Objective-C DRMAA implementation. As long as Xgrid is  
compliant for C and Java, that should be good enough, I think.

--Ed

On Jun 6, 2006, at 5:26 PM, Daniel Templeton wrote:

> Ed,
>
> I think I had the same conversation with Peter about the .Net  
> implementation.  Because of the Java binding, the deleteJobTemplate 
> () method also made it into the IDL spec.  Peter's goal with the  
> IDL spec was to be able to effectively generate the other binding  
> specs by applying different mappings to the IDL spec.  If you leave  
> out the delete method, your binding won't be IDL-compliant.  Of  
> course, since you're not writing a binding spec for it, that  
> shouldn't matter.
>
> Peter, care to add anything?  Should we revisit this discussion?
>
> Daniel
>
> Ed Baskerville wrote:
>> OK, I buy that. Since Cocoa uses a manual retain/release/refcount  
>> system for memory management, it should be fine to leave out  
>> "delete" in the native Objective-C XgridDRMAA implementation and  
>> put it in the dealloc method (the Cocoa equivalent of a  
>> finalizer). In C and Java, then, the job-template creation method  
>> will alloc/init a new ObjC object (giving it a refcount of 1); and  
>> delete will release it (decrementing its refcount to 0 and calling  
>> dealloc).
>>
>> --Ed
>>
>> On Jun 5, 2006, at 5:26 PM, Daniel Templeton wrote:
>>
>>> 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
>>>>
>>>
>>
>