Free BSTR/Variant allocated in COMLateBindingObject#setProperty(String, String)

[matthiasblaesing]

No description provided.

[dbwiddis]

This change looks good.

However, something to consider. Users may have a similar use case for types VT_DISPATCH and VT_ARRAY.

We already have (next method below) a setProperty(String propertyName, VARIANT value) that does oleMethod() call so we could simply delegate. Or, better, you could define a new overloaded function which users could use an optional boolean parameter similar to OaIdlUtil.toPrimitiveArray()'s destruct parameter or Convert.toJavaObject()'s freeValue parameter:

protected void setProperty(String propertyName, VARIANT value, boolean clear) {
    try {
        setProperty(propertyName, value);
    } finally {
        if (clear) {
            OleAuto.INSTANCE.VariantClear(value);
        }
    }
}

and then simply do

protected void setProperty(String propertyName, String value) {
    setProperty(propertyName, new VARIANT(value), true);
}

[matthiasblaesing]

I think the biggest issue with COM in JNA is the overcomplicated binding for the COM invokers and the VARIANT binding. If the basic interface would be closer to the metal, it would be easier to reason with it.

I would not tinker with a VARIANT I did not create - the user created it, the user can clear it (or not if it is appropriate). The String -> BSTR case is different. In that case we explicitly create a reference counted object (the BSTR) and the user has no control over this.

I saw the Dispatch and IDispatch cases, but also in that case, we just wrap the VARIANT around an existing object without tinkering with the reference count, so the VARIANT is only the structure, nothing more.

[dbwiddis]

LGTM. Probably would have done this myself in my last PR, but didn't understand when it was OK to clear the variant.

One suggestion inline.

[matthiasblaesing]

Thanks for the check!