QueryInterface returns wrong interface in JACOB 1.17

Question

I am trying to use JACOB 1.17 (latest stable version) to access a 64-bit in-process COM server, i.e. MyObject-x64.dll .

My CoClass has two dualinterfaces: IFoo (default), and IBar. IFoo contains foo_method(), and IBar contains bar_method(). Both methods have dispatch ID of 1.

My Java code is:

import com.jacob.activeX.ActiveXComponent;
import com.jacob.com.Dispatch;
import com.jacob.com.LibraryLoader;
import com.jacob.com.Variant;

// ...

ActiveXComponent my_object = new ActiveXComponent("MyObject.MyClass");    // OK
Dispatch.call(my_object, "foo_method");    // OK
Dispatch ibar = my_object.QueryInterface("{DE3FF217-120B-4F1E-BEF5-098B8ABDEC1F}");    // OK
Dispatch.call(ibar, "bar_method");    // Exception - "Can't map names to dispid:bar_method"
Dispatch.getIDOfName(ibar, "bar_method");    // Exception - "Can't map names to dispid:bar_method"
Dispatch.call(ibar, "foo_method");    // OK, executes foo_method
Dispatch.call(ibar, 1);    // OK, executes foo_method

So, it seems that either the QueryInterface has returned the wrong interface, or the call function on ibar is calling the default interface instead of the result of the QueryInterface.

I have had a quick look through the JNI source code for jacob-1.17-x64.dll and can't see any obvious problem with the QueryInterface implementation or with the call implementation, although I haven't looked at JNI code before so I may be missing something obvious.

There is a sample that comes with JACOB, samples/com/jacob/samples/atl which accesses multiple interfaces, and it uses QueryInterface the same as I have. However I can't run this sample as it requires a MultiFace.dll which is not provided. (Source is provided but it is MSVC++-specific source, and I don't use MSVC++).

The IID in QueryInterface is definitely correct , and my object definitely isn't broken; I can access IBar fine using a free trial of one of the commercial Java-COM bridges, as well as from Visual Basic.

Is JACOB bugged or am I doing something wrong?

Using JRE 1.7.0_51-b13 .

Answer 1

Actually, Jacob is OK. The problem is that C++Builder XE5 has bugged implementation of IDispatch. If you QueryInterface for IDispatch plus the IID of the interface you want, then you get a valid pointer, however it actually points to the original interface you queried from, not the new one.

The other access methods all must be using vtable binding, so they did not encounter a problem.

Leaving this answer here in case anyone else has the same issue and searches.

So far, I have not discovered a workaround.