rik/jlibcom
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

B-1_14-DEV merge back to main

Browse Source
This commit is contained in:
clay_shooter
2008-02-02 01:38:25 +00:00
parent cd58b57a99
commit df0ba33797
97 changed files with 12208 additions and 8816 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/BuildingJacobFromSource.html
View File

@@ -34,20 +34,20 @@ been removed.
<p>
<H1>Development Environment</h1>
The simplest build environment includes MS Visual C++ 8.0 (Studio 2005),
Eclipse 3.3 with the C/C++ module and JDK 1.4.
Eclipse 3.3 with the C/C++ module and JDK 1.5.
In that situation, you would just create the <i>compilation_tools.properties</i>
using the example build.xml as a template.
<UL>
<li> Microsoft Visual C++ 8.0 and it's included library. (to D:\apps in my case)
<li> Eclipse 3.3 or later from www.eclipse.org as the Java IDE.
<li> Eclipse 3.3 or later with the C/C++ plugin can be used for C coding in place of VC++ IDE.
<li> Java JDK 1.4 (1.12 was built using 1.4.2.13) Compilation using JDK 1.5 has not been tested
<li> Java JDK 1.5 (1.14 was built using 1.5.0.11)
</ul>
<p>
<p>
<table>
<TR><TD>Release</TD><TD>C Version</TD><TD>Java Version</TD><TD>ANT Version</TD><TD>Eclipse Version Used</TD><TD>generated DLLs</TD></TR>
<TR><TD>up to 1.6</TD><TD>VC 98 (6.0)</TD><TD>?</TD><td>Used MAKE</td><TD>?</TD><TD>32 bit</TD></TR>
<TR><TD>up to 1.6</TD><TD>VC 98 (6.0)</TD><TD>?</TD><td>MAKE</td><TD>?</TD><TD>32 bit</TD></TR>
<TR><TD>1.7</TD><TD>VC 98 (6.0)</TD><TD>1.4</TD><td>1.?</td><TD>?</TD><TD>32 bit</TD></TR>
<TR><TD>1.8</TD><TD>VC 98 (6.0)</TD><TD>1.4</TD><td>1.?</td><TD>?</TD><TD>32 bit</TD></TR>
<TR><TD>1.9</TD><TD>VC 98 (6.0)</TD><TD>1.4</TD><td>1.?</td><TD>?</TD><TD>32 bit</TD></TR>
@@ -55,6 +55,7 @@ using the example build.xml as a template.
<TR><TD>1.11</TD><TD>VC 98 (6.0) & 2003 64bit libs</TD><TD>1.4.?</TD><td>1.6.?</td><TD>3.2.1</TD><TD>32 and 64 bit</TD></TR>
<TR><TD>1.12</TD><TD>VC 98 (6.0) & 2003 64bit libs</TD><TD>1.4.2</TD><td>1.6.5</td><TD>3.2.2</TD><TD>32 and 64 bit</TD></TR>
<TR><TD>1.13</TD><TD>VC 2005</TD><TD>1.4.2</TD><TD>1.7.0</TD><TD>3.3</TD><TD>32 and 64 bit</TD></TR>
<TR><TD>1.14</TD><TD>VC 2005</TD><TD>1.5.0</TD><TD>1.7.0</TD><TD>3.3</TD><TD>32 and 64 bit</TD></TR>
</table>
Microsoft Visual C++ 8.0 supports 64 bit builds. so no additional tools are required.

115
docs/ReleaseNotes.html
View File

@@ -1,5 +1,113 @@
<HTML>
<BODY>
<!-- --------- -->
<h2>JACOB 1.14</h2>
<h3>What's New</h3>
<ul>
<li>
Binaries are now compiled with Java 5. JDK 1.4 support dropped.
</li>
<li>
Jacob now loads dlls based on platform (32 bit /64 bit) and version number.
</li>
</ul>
<h3>Tracked Changes</h3>
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%" >
<tr>
<td width="100%" colspan="2"><b>Bugs</b></td>
</tr>
<tr>
<td width="13%" valign="top">1857439</td>
<td width="87%" valign="top">(M7) version.properties renamed to META-INF/JacobVersion.properties
to remove collision with WebSphere version.properties.</td>
</tr>
<tr>
<td width="13%" valign="top">1840487</td>
<td width="87%" valign="top">(M6) toJavaObject() converting to SafeArray
did shallow copy that left two objects pointing at the same windows memory.</td>
</tr>
<tr>
<td width="13%" valign="top">1829201</td>
<td width="87%" valign="top">(M5) DECIMAL rounding behavior externalized
and old Variant decimal API restored.</td>
</tr>
<tr>
<td width="13%" valign="top">1829201</td>
<td width="87%" valign="top">(M5) DECIMAL rounding behavior externalized
and old Variant decimal API restored.</td>
</tr>
<tr>
<td width="13%" valign="top">1829201</td>
<td width="87%" valign="top">(M4) Decimal type now throws IllegalArgumentException
when more than 12 bytes worth the digits exist in BigDecimal. Rounding
support added to reduce precision of BigDecimals when converting into VT_DECIMAL</td>
</tr>
<tr>
<td width="13%" valign="top">1815163</td>
<td width="87%" valign="top">(M2) Double and Decimal conversion to Int fails for negative values</td>
</tr>
<tr>
<td width="13%" valign="top">&nbsp;</td>
<td width="87%" valign="top">&nbsp;</td>
</tr>
<tr>
<td width="100%" colspan="2"><b>Patches</b></td>
</tr>
<tr>
<td width="13%" valign="top">&nbsp;</td>
<td width="87%" valign="top">&nbsp;</td>
</tr>
<tr>
<td width="100%" colspan="2"><b>Feature Requests</b></td>
</tr>
<tr>
<td width="13%" valign="top">1845039 </td>
<td width="87%" valign="top">(M7) Jacob DLL name can now be customized to
support bundling of Jacob in other products.</td>
</tr>
<td width="13%" valign="top">1845039 </td>
<td width="87%" valign="top">(M6) Jacob DLL names are now qualified by platform and
release. The JacobLibraryLoader now determines the correct 32bit or 64bit
dll based on the system architecture. Jacob.jar now also knows the version
of the dll it is looking for (by name) and loads the correct one. JWS clients
will have to modify their dll loaders. See: The JWS classloader sample </td>
</tr>
<tr>
<td width="13%" valign="top">1828371 </td>
<td width="87%" valign="top">(M4) Added VT_I8 support to SafeArray.</td>
</tr>
<tr>
<td width="13%" valign="top">1813458</td>
<td width="87%" valign="top">(M3) Expand type support. Changed currency support
to use new Currency class. Added VT_I8 64 bit support. VT_I8 support
requires Windows XP or later. VT_I8 not supported by windows in
Windows 2000 and earlier. Added more primitive constructors to Variant.</td>
</tr>
<tr>
<td width="13%" valign="top">1816863</td>
<td width="87%" valign="top">(M1) Migrate Jacob to JDK 5</td>
</tr>
<tr>
<td width="13%" valign="top">&nbsp;</td>
<td width="87%" valign="top">&nbsp;</td>
</tr>
<tr>
<td width="100%" colspan="2"><b>Known Issues</b></td>
</tr>
<tr>
<td width="13%" valign="top"></td>
<td width="87%" valign="top">This is now built with Java 5 compiler and
Java 5 syntax. This release is not compatible with JDK 1.4.x and earlier.</td>
</tr>
<tr>
<td width="13%" valign="top"></td>
<td width="87%" valign="top">This release requires the Visual C++ 2005
libraries. See 1.13 Known Issues for more information.</td>
</tr>
</table>
<!-- --------- -->
<h2>JACOB 1.13</h2>
<h3>What's New</h3>
@@ -82,11 +190,14 @@
<td width="100%" colspan="2"><b>Known Issues</b></td>
</tr>
<tr>
<td width="13%" valign="top">VC++ libraries</td>
<td width="13%" valign="top"></td>
<td width="87%" valign="top">Jacob 1.13 is built using VC++ 2005.
That creates a dependency on the Visual C++ 2005 libraries and msvcr80.dll.
This library is normally installed on XP systems but may have to be manually
installed on older systems. It can be obtained from the MS downloads site.</td>
installed on older systems. The pagackage, often referred to as vcredist.exe
can be obtained from the MS downloads site.
If you are getting loader errors on this release or later when loading the
dll then you may be missing this library.</td>
</tr>
</table>

118
docs/UsingJacob.html
View File

@@ -23,6 +23,16 @@ to provide a more object like API.
The only exception to this guideline is that the <code>ActiveXComponent</code> class is always
used to make the initial connection to the target dll/COM component.
<hr>
<H2> Considerations when doing server side automation of office </h2>
<p>
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
<a href="http://support.microsoft.com/kb/257757/">
support note </a>
on the Microsoft web site that discusses some of the issues.
<p>
<hr>
<H2> Determining the API of the target application </h2>
<p>
@@ -32,14 +42,22 @@ Section not yet written.
<h2> The Jacob DLL </h2>
<p>
Jacob.jar relies on a DLL file that it loads off of the library path or classpath.
This means that you must either copy jacob.dll into your path or use VM options to
add jacob.dll directory to the path.
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: <BR>
<code>jacob&lt;platform&gt;.&lt;version.&gt;.dll</code>
<p>
<h3>Classloader issues</h3>
The code is written so that the jacob.dll is only loaded one time per classloader.
This works fine in the standard application but can cause problems if jacob.jar
is loaded from more than one class loader. This can happen in the situation where multiple
jacob dependent web applications run in the same container like a web server or JWS runtime.
<p>
In the case of a web server, Jacob is normally put in the application specific WEB-INF/lib directory.
This is the "right" way to do it and works in most situations.
But, if Jacob is put in the WEB-INF/lib directory of each application's war file for more than
@@ -71,16 +89,54 @@ oblem
Visual C redistributable installer SP1</A>
</pre>
<p>
<p></p>
<hr>
<h2>Jacob Command Line Settings</h2>
This library supports several different :
<h3>java.library.path</h3>
Used to add the location of the jacob dll to the JVM's library path.
This library supports several differentommand line options:
<table border=1>
<tr><td colspan=3>
<h3>dll path location and dll name customization</h3>
</td></tr>
<tr><td>&nbsp;&nbsp;&nbsp;</td><td valign="top">
<h4>java.library.path</h4>
</td><td>
Standard Java property used to add the location of the jacob dll to the JVM's library path.
(Added 1.11)
<p>
Example: -Djava.library.path=d:/jacob/release/x86
Example: <code>-Djava.library.path=d:/jacob/release/x86</code>
</td></tr>
<h3>com.jacob.autogc </h3>
<tr><td>&nbsp;&nbsp;&nbsp;</td><td valign="top">
<h4>jacob.dll.name</h4>
</td><td>
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)
<p>
Example: <code>-Djacob.dll.name=MyFunkyDllName.dll</code>
</td></tr>
<tr><td>&nbsp;&nbsp;&nbsp;</td><td valign="top">
<h4>jacob.dll.name.x86 & jacob.dll.name.x64</h4>
</td><td>
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)
<p>
Example to override 32 bit dll name: <code>-Djacob.dll.name.x86=MyFunkyDllName-32bit.dll</code>
</td></tr>
<tr><td colspan=3>
<h3>Memory Management</h3>
</td></tr>
<tr><td>&nbsp;&nbsp;&nbsp;</td><td valign="top">
<h4>com.jacob.autogc </h4>
</td><td>
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
<code>com.java.autogc</code> command line option.
@@ -95,16 +151,20 @@ This library supports several different :
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 <a href="JacobComLifetime.html">JacobComLifetime.html</a> document
says this is a bad idea.
says this is a bad idea. Added 1.9.
<p>
<p>
This value is cached at startup and cannot be changed on-the-fly via <code>System.setProperty();</code>
<p>
The default value is <strong>false</strong>
The default value is <em>false</em>
<p>
Example: <code>-Dcom.jacob.autogc=false</code>
<h3>&ltclass_name&gt.PutInROT</h3>
</td></tr>
<tr><td>&nbsp;&nbsp;&nbsp;</td><td valign="top">
<h4>&ltclass_name&gt.PutInROT</h4>
</td><td>
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
@@ -116,7 +176,7 @@ This library supports several different :
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. <em>This function is still experimental</em>.
The functionality of this overlaps the experimental <code>com.jacob.autogc</code> introduced
The functionality was added 1.13. Some of this overlaps the experimental <code>com.jacob.autogc</code> introduced
in 1.9.
See the ROT.java test program for an example of the effects of this option.
<p>
@@ -126,8 +186,14 @@ This library supports several different :
Example: <code>System.setProperty("com.jacob.com.VariantViaVariant.PutInROT","false");</code>
<BR>
Example: <code>-Dcom.jacob.com.VariantViaVariant.PutInROT=false</code>
</td></tr>
<h3>com.jacob.debug</h3>
<tr><td colspan=3>
<h3>Debugging and Troubleshooting</h3>
</td></tr>
<tr><td>&nbsp;&nbsp;&nbsp;</td><td valign="top">
<h4>com.jacob.debug</h4>
</td><td>
Determines if debug output is enabled to standard out.
<p>
This value is cached at startup and cannot be changed on-the-fly via <code>System.setProperty();</code>
@@ -136,14 +202,21 @@ This library supports several different :
<p>
Example: <code>-Dcom.jacob.debug=false</code>
</td><tr>
<h3>-XCheck:jni</h3>
<tr><td>&nbsp;&nbsp;&nbsp;</td><td valign="top">
<h4>-XCheck:jni</h4>
</td><td>
This turns on additional JVM checking for JNI issues. This is
not an actual JACOB system property but a property used by the JVM.
<p>
The default is "no additional checking"
Example: -XCheck:jni
<p>
Example: <code>-XCheck:jni</code>
</td></tr>
</table>
<p></p>
<hr>
<h2>Finding the DLL version using windows command line</h2>
The jacob.dll file includes the jacob release number in the version field.
@@ -153,8 +226,17 @@ The dll version number is stored in the "image version" field of the
This information from <a href="http://msdn2.microsoft.com/en-gb/library/h88b7dc8(VS.71).aspx">
The Microsoft msdn web site</a>
<hr>
<h2>Unit Tests</h2>
Jacob must know the location of the DLL when running the unit tests in Eclipse.
The simplest way to do this is to add the dll path to the unit as a VM argument.
The argument should be specified based on where you installed the jacob source package.
If you have jacob unpacked in d:/jacob_1_5 and built using build.xml,
then the vm arguments would be:
<br><code>-Djava.library.path=d:/jacob_1_5/release/x86</code> .
<p>
Last Modified 7/2007
Last Modified 12/2007
</BODY>
</HTML>