You can either
(1) ensure that your CLASSPATH includes the ucanaccess-x.x.x.jar
and the four (4) jar files in the "lib" directory of the UCanAccess distribution,
or
(2) ensure that your CLASSPATH includes just the ucanload.jar
from the "loader" folder, and set a Java system property named UCANACCESS_HOME
when you launch the Java virtual machine, e.g., by using the -Dproperty=value
switch
-DUCANACCESS_HOME=<directory into which you unpacked the UCanAccess binary distribution>
That is, UCANACCESS_HOME
must point to the directory that directly contains ucanaccess-x.x.x.jar
after decompressing the UCanAccess distribution zip file. For example:
-DUCANACCESS_HOME=/home/gord/Downloads/JDBC/UCanAccess-3.0.1-bin
The two configurations are mutually exclusive.
The first one is the generally adopted one.
The second one leverages the JDBC driver classloading mechanism in order to load dependencies with a different classloader. If an application already uses specific versions of HSQLDB, commons-lang, commons-logging, and/or Jackcess then ucanload.jar
can be used to avoid conflicts between different versions of those jars eventually used by your application. In other words, using this approach you can be sure that your application continues to use the (other) versions of HSQLDB, commons-lang, commons-logging, and/or Jackcess that it used before, while UCanAccess uses the ones in its distribution.