Version 1.6 and Earlier Release Notes and Credits

Version 1.6 fixes the SafeArray problems. Variant.toSafeArray() now makes a deep copy by default. Use Variant.toSafeArray(false) to get the old functionality (no deep copy - but result is only valid as long as the owning Variant is valid). If you stick to the defaults, SafeArray now keeps track of who owns the memory and does the right thing.

The November 5 distribution finally starts using a version number: 1.5 is the current version. This version fixes a number of bugs recently reported on the mailing list, as well as adds support for accessing non-default COM interfaces. Under samples\test there is a new directory called atl and that has a COM object with 3 interfaces, plus a file MultiFace.java that demonstrates how to use the new Dispatch.QueryInterface method to access non-default interfaces.

The October 7 distribution fixes a bug when the COM object returns a Variant with an empty Dispatch pointer. In VB, this is called 'Nothing'. The toDispatch() method now checks for this, and there is also a new method on Variant called 'isNull()' which returns true when the underlying Variant is 'Nothing', 'Empty', 'Null' or has a NULL safe array in it. The "math.java" sample program adds a test for this feature.

The July 30, 2000 distribution just adds a servlet example which demonstrates how JACOB can be used to wrap a COM object for use in a servlet. This example has been tested in Weblogic 5.1. The example can be found in the samples/servlet directory.

The July 22, 2000 distribution includes a move away from the Single Threaded Apartment model. JACOB now initializes COM in multit-hreaded mode. The major obstacle to doing this in the past was that COM events delivered to Java through Connection Points, were blocking. Ng Hu Chong of Retail Store Solutions, found that the problem was that I was using the JNIEnv pointer from the wrong thread, and he suggested a way to get the current VM, attach to the current thread making the callback, and obtain the JNIEnv from that thread. This solves the callback issue. Remember that you may now have to use synchronized blocks in your java code to solve standard concurrency issues. More information on the free threaded model can be found in the following MSJ article: Fashionable App Designers Agree: The Free Threading Model is What's Hot This Fall.

The July 16, 2000 distribution includes a jumbo patch which was contributed by Toyokazu Tomatsu. Toyokaza solved one of the issues that was annoying many European and Asian users, which is that my original JNI code did not correctly deal with non-US character sets.

You can see the details of how Toyokazu is using JACOB to integrate Pnuts with COM.

Credits

• Toyokazu Tomatsu suggested a number of fixes for the July 16, 2000 release.

Bug Fixes

• Tim Teague has reported that the following two lines will cause the HotSpot jit to crash completely:

  
    Object o = new String("test");
    Variant v = new Variant(o);
  
  

  This problem has been fixed in the Oct 30, 1999 distribution.
• Tim McBride found that it was impossible to extract a VT_DISPATCH from a SafeArray. It turns out that the way to do it in the API is to use getVariant/setVariant on the SafeArray. The following snippet (found in samples/test/sa_dispatch.java) demonstrates this. I wrap a script control dispatch in a variant, push it into a safe array, pull it back out - and use it to eval an expresion like "1+1".

  
        String lang = "VBScript";
        ActiveXComponent sC = new ActiveXComponent("ScriptControl");
        Dispatch sControl = (Dispatch)sC.getObject();
        Dispatch.put(sControl, "Language", lang);
  
        Variant result = Dispatch.call(sControl, "Eval", args[0]);
        System.out.println("eval("+args[0]+") = "+ result);
  
        // wrap the script control in a variant
        Variant v = new Variant(sControl);
  
        // create a safe array of type dispatch
        SafeArray sa = new SafeArray(Variant.VariantDispatch, 1);
  
        // put the variant in the array
        sa.setVariant(0, v);
  
        // take it back out
        Variant v2 = sa.getVariant(0);
        Dispatch d = v2.toDispatch();
  
        // make sure you can call eval on it
        result = Dispatch.call(d, "Eval", args[0]);
        System.out.println("eval("+args[0]+") = "+ result);
  
  

  This problem has been fixed in the Jan 9, 2000 distribution.
• Leon Lambert pointed out two bugs in the implementation of the Variant BYREF handling. First, I was placing a CComBSTR into the result, which was a stack variable and was getting freed. Then, I was not freeing it. The two modifications are in Variant.cpp: Java_com_jacob_com_Variant_putStringRef and Java_com_jacob_com_Variant_release. In general, this has been one of the top questions: how to get back INOUT or OUT variables. The answer is to use the "byref" variant methods, and with this fix, it should work. This problem has been fixed in the June 18, 2000 distribution.
• Tim McBride also found out that I faithfully reproduced one of the most annoying bugs in microsoft's java-com bridge, which is the fact that SafeArray's are not safe. When otained from a Variant, the SafeArray is still owned by its parent, so whenever the Variant goes out of scope (COM-wise), the SafeArray is destroyed. Therefore, always make a copy before storing references to SafeArrays.