Jacob is not used for creating ActiveX plugins or other moduless that live inside of Microsoft Windows applications.
The JACOB jar contains two main packages: the com.jacob.com.*
> package and
the com.jacob.activeX
package. The com.jacob.com.*
package contains classes
map very closely to the com dispatch model with the com.jacob.com.Dispatch
acting as the primary communication class. Dispatch operate as a function library with
a set of static methods that map very closely to the C++ Dispatch APIs provided
to the COM layer.
com.jacob.activex.ActiveXComponent
can be used in place of Dispatch
to provide a more object like API.
The only exception to this guideline is that the ActiveXComponent
class is always
used to make the initial connection to the target dll/COM component.
Most office and many windows client type applications are not written to be used in high volume or multi-threaded server environment. There is a support note on the Microsoft web site that discusses some of the issues.
Section not yet written.
Jacob.jar relies on a DLL file that it loads off of the library path or classpath.
This means that you must either copy the appropriate jacob ddll into your path or
use VM options to add directory holding jacob dll to the path. Prior to 1.14M6,
the jacob DLL name was alwasy "jacob.dll". This made it hard to verify jacob
was loading the correct dll when multiple copies of jacob were installed on a
single system. It also was confusing on 64 bit systems where the 32 bit and 64 bit
dlls have the same tames.
Starting in 1.14M6, Jacob's library
loader selects a dll with the appropriate name based on the jacob release and platform.
The dll naming convention is:
jacob<platform>.<version.>.dll
If you see the following message then you probably don't have the right C++ libraries.
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\apps\...\jacob.dll: This application has fa iled to start because the application configuration is incorrect. Reinstalling the application may fix this pr oblem
Visual C redistributable installer SP1
dll path location and dll name customization | ||
java.library.path |
Standard Java property used to add the location of the jacob dll to the JVM's library path.
(Added 1.11)
Example: | |
jacob.dll.name |
Override the standard DLL name with a custom one. This stops jacob from
using its 32bit/64bit detection and dll rendevous logic.
Sometimes used when
Jacob is bundled with another application and the application wishes
to tie the jacob dll version number to the application version numbber.
(Added 1.14M7)
Example: | |
jacob.dll.name.x86 & jacob.dll.name.x64 |
Override the standard 32 bit DLL name with custome ones.
Sometimes used when
Jacob is bundled with another application and the application wishes
to tie the jacob dll version number to the application version numbber.
(Added 1.14M7)
Example to override 32 bit dll name: | |
Memory Management | ||
com.jacob.autogc |
Determines if automatic garbage collection is enabled. This is the
only way to free up objects created in event callbacks. Automatic garbage collection , based on Java gc rules, garbage collection can be enabled via the
com.java.autogc command line option.
This feature was added in release 1.9 is not fully debugged.
There are real reasons for managing the lifetime of JacobObjects on a per thread basis. Jacob normally manages the the com/Java object lifetime as described in the JacobComLifetime.html document. Some users have run into situations where they wish to try and let the Java GC lifetime manage the lifetime of objects. This seems to usually be tied to long running threads or to objects created as part of event callbacks. Code was added to let users try and let the JVM manage the object life cycles even though the JacobComLifetime.html document says this is a bad idea. Added 1.9.
This value is cached at startup and cannot be changed on-the-fly via The default value is false
Example: | |
<class_name>.PutInROT |
Lets a program specify that instances of certain classes are to not be inserted
into the ROT. This experimental (1.13) feature provides a mechanism for freeing
VariantViaEvent objects that are created in Event threads. There is normally no
way to free those objects because the thread terminates outside of any normaly MTA/STA
Startup/Teardown code. Each event occures in a new thread and creates a new ROT entry
so they grow without bounds.
This option may cause VM crashes in certain situations where windows memory is freed
outside of the thread it was created in but emperical evidence shows there are
situations where this great reduces the long running memory footprint of applications
that process a lot of events. This function is still experimental.
The functionality was added 1.13. Some of this overlaps the experimental
This value is checked every time and can be changed on-the-fly via
Example: | |
Debugging and Troubleshooting | ||
com.jacob.debug |
Determines if debug output is enabled to standard out.
This value is cached at startup and cannot be changed on-the-fly via The default value is false
Example: | |
-XCheck:jni |
This turns on additional JVM checking for JNI issues. This is
not an actual JACOB system property but a property used by the JVM.
The default is "no additional checking"
Example: |
dumpbin /version jacob.dll
.
The dll version number is stored in the "image version" field of the
"OPTIONAL HEADER VALUES" section.
This information from
The Microsoft msdn web site
-Djava.library.path=c:/dev/jacob/release/x86
.
Last Modified 4/2008 1.15