We are running on Windows 7 Enterprise, SP1, 64bit. We just installed Java 7 on all our machines, which causes the following problem:
When my program tries to communicate with the OpenTestArchitecture-API from Quality Center it fails to create the ActiveX-Component. I use JACOB as my Java-COM library. Upgrading to the latest version of JACOB does not change anything.
The following test works with jdk1.6.0_24 (32 bit) but fails with jdk1.7.0_04 (32 bit):
import java.io.File;
import com.jacob.activeX.ActiveXComponent;
import com.jacob.com.ComThread;
import com.jacob.com.Dispatch;
import com.jacob.com.LibraryLoader;
public class JacobTest {
static {
File lib = new File("lib/" + LibraryLoader.getPreferredDLLName() + ".dll");
System.setProperty(LibraryLoader.JACOB_DLL_PATH, lib.getAbsolutePath());
System.out.println("JACOB_DLL_PATH = " + lib.getAbsolutePath());
LibraryLoader.loadJacobLibrary();
}
public static void main(String[] args) {
try {
// Excel: Works with jdk1.6.0_24 AND jdk1.7.0_04
System.out.println("new ActiveXComponent(\"Excel.Application\");");
new ActiveXComponent("Excel.Application");
// Quality Center OTAClient: Only works with jdk1.6.0_24
System.out.println("ActiveXComponent component = new ActiveXComponent(\"TDApiOle80.TDConnection\");");
ActiveXComponent component = new ActiveXComponent("TDApiOle80.TDConnection");
System.out.println("ComThread.InitSTA();");
ComThread.InitSTA();
System.out.println("Dispatch.call(component, \"InitConnectionEx\", \"http://intranet/qcbin\");");
Dispatch.call(component, "InitConnectionEx", "http://intranet/qcbin");
}
catch (Exception exception) {
exception.printStackTrace();
}
}
}
jdk1.6.0_24 output:
JACOB_DLL_PATH = C:\Development\Java\Test\JacobTest\lib\jacob-1.17-M2-x86.dll
new ActiveXComponent("Excel.Application");
ActiveXComponent component = new ActiveXComponent("TDApiOle80.TDConnection");
ComThread.InitSTA();
Dispatch.call(component, "InitConnectionEx", "http://intranet/qcbin");
jdk1.7.0_04 output:
JACOB_DLL_PATH = C:\Development\Java\Test\JacobTest\lib\jacob-1.17-M2-x86.dll
new ActiveXComponent("Excel.Application");
ActiveXComponent component = new ActiveXComponent("TDApiOle80.TDConnection");
com.jacob.com.ComFailException: Invalid access to memory location.
at com.jacob.com.Dispatch.createInstanceNative(Native Method)
at com.jacob.com.Dispatch.<init>(Dispatch.java:99)
at com.jacob.activeX.ActiveXComponent.<init>(ActiveXComponent.java:58)
at JacobTest.main(JacobTest.java:26)
The original ComFailException-Message is "Can't co-create object" but I've edited the following Code in the jacob Dispatch.cpp: (I didn't touch CoCreateInstance, I just wanted to know what the HRESULT was)
// standard creation
hr = CoCreateInstance(clsid,NULL,CLSCTX_LOCAL_SERVER|CLSCTX_INPROC_SERVER,IID_IUnknown, (void **)&punk);
if (!SUCCEEDED(hr)) {
if (hr == REGDB_E_CLASSNOTREG)
ThrowComFail(env, "Can't co-create object: REGDB_E_CLASSNOTREG", hr);
if (hr == CLASS_E_NOAGGREGATION)
ThrowComFail(env, "Can't co-create object: CLASS_E_NOAGGREGATION", hr);
if (hr == E_NOINTERFACE)
ThrowComFail(env, "Can't co-create object: E_NOINTERFACE", hr);
if (hr == E_POINTER)
ThrowComFail(env, "Can't co-create object: E_POINTER", hr);
_com_error error(hr);
LPCTSTR errorText = error.ErrorMessage();
ThrowComFail(env, errorText, hr);
return;
}
Does anyone have a clue what the problem could be? The only difference is that I switch between the Java 6 and Java 7 runtime.
Thanks very much for your help!
PS: Excel works with both versions and a switch to the com4j-Library does not change anything. (I have a com4j-Test, but I didn't post it because I've already posted enough code)
Edit: The same test works with Windows XP, SP3 and Java 7.
Jacob DLL is linked with jvm.dll
(methods and structures) from the JRE. So my guess is that the Jacob DLL should be compiled from sources with Java 7 to load properly into Java 7 JRE.
You are not alone but I guess too few people are already running Java 7...
Update: I propose you investigate first with Process Monitor if there are some library or system calls failing in your Java process, before running the process itself in a debugger... Maybe OpenJDK 7 may be an option to try too, it should be easier to debug then, at least to diagnose what the problem is.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With