RecAPI
All Classes Namespaces Functions Variables Typedefs Enumerations Enumerator Properties Modules Pages
RecAPI Java support

OmniPage CSDK v21.1 has introduced Java API to access KernelAPI, RecAPIPlus and RecPDF functions in Java. The mapping code is autogenerated by SWIG reflecting our C API, and using JNI (Java Native Interface). This autogenerated behaviour, and the functions offered in Java try to reflect exactly the same functions with mostly same parameters. See JavaSamples bundled with this CSDK to see the example usages.

Installation

Java API does not require any extra step after a normal install of CSDK. Instead, the user has to locate omnipage_csdk.jar inside a CSDK installation "bin" folder and include it in the java classpath.

Samples

After installing the CSDK, Java samples are available here:

C:\ProgramData\OmniPage\CSDK22\x64\Samples\Java

For a 32-bit CSDK install, please replace x64 by x86 everywhere in this Java section.
To use the prepared .cmd files in this directory (build.cmd and run.cmd), user has to set JAVA_HOME environment variable properly (e.g. "C:\Program Files\Java\jdk1.8.0_77").
These .cmd files are are very simple 1-liner texts, so you should definitely open and examine them later - everything possible to be run without setting JAVA_HOME then.
In order to build JavaSample, open a dos prompt or powershell in the directory above, and issue build.cmd.
It compiles java files under:

C:\ProgramData\OmniPage\CSDK22\x64\Samples\Java\JavaSamples

Now you can run it:

C:\ProgramData\OmniPage\CSDK22\x64\Samples\Java> run.cmd -h
Loading csdk_omnipage.dll...Arguments captured: -h
Usage:
JavaSamples OPTION ID
ID could be 1-109 or all
-d ID prints the description of sample ID to stdout
-f ID prints the function list of sample ID to stdout
-x ID executes sample ID, writes all the messages to stdout
-all executes all samples, writes all the messages to stdout
-h|? prints this help


C:\ProgramData\OmniPage\CSDK22\x64\Samples\Java> run.cmd 1
Loading csdk_omnipage.dll...Arguments captured: 1
Input folder: C:\ProgramData\OmniPage\CSDK22\x64\Samples\Inputs\
Output folder: C:\Users\<user>\OmniPage\CSDK22\SamplesOutput\Java\
INF > ** Title: OmniPage Capture Development System Java Sample001 Application **
INF > Initializing the Engine -- kRecInit()
INF > Inquiring the version number of Capture SDK -- kRecGetVersion()
...
INF > Free all resources allocated by the Engine -- kRecQuit()
INF > End of Sample01 application
The sample passed
RECERR RECAPIKRN kRecQuit(void)
Closing KernelAPI.
int RECAPIKRN kRecGetVersion(void)
Getting version.
RECERR RECAPIKRN kRecInit(LPCTSTR pCompanyName, LPCTSTR pProductName)
Initializing KernelAPI.

Note: color codes are being used by JavaSamples for dos prompt. In case you are not seeing the colors, then you need to open registry, and create in HKCU\Console a DWORD named VirtualTerminalLevel and set it to 0x1.
Initialization

import com.omnipage.csdk.JNILoader;
import com.omnipage.csdk.JNILoaderException;
static {
out.print("Loading csdk_omnipage.dll...");
try {
JNILoader.LoadJNI();
} catch(JNILoaderException e) {
e.printStackTrace();
}
}

The function LoadJNI() tries to load csdk_omnipage.dll from the same directory as csdk_omnipage.jar.
It also has a version with a parameter, allowing to find the dll using a relative path to this jar file :

public static void LoadJNI(String relPath) throws JNILoaderException

In case of a repackaged installation for a 3rd party use would put CSDK binaries in various folders, the csdk_omnipage.dll has to be loaded manually:

import com.omnipage.csdk.*;
System.loadLibrary("<path_to_csdk_binaries>\csdk_omnipage");

In this case, user has to provide the absolute file path to csdk_omnipage.dll by Java code.
Further necessary omnipage dlls are loaded on demand automatically from exactly the same directory of the already loaded csdk_omnipage.dll.
User has to guarantee that csdk_omnipage.jar and csdk_omnipage.dll are from exactly the same CSDK version when dislocating them.

The csdk_omnipage.dll will look for other necessary DLLs exactly in the same folder where it was loaded from, but only after any of a later kRecInit / RecInitPlus / rPdfInit calls.
Starting from CSDK version 22.0, the extension of PATH variable is not required.
After this necessary runtime step, you can instantiate the main class encapsulating the CSDK API and then use it afterward:

RecAPI recapi = new RecAPI();

After acquiring the above RecAPI instance, your first real omnipage CSDK call should be any of kRecInit, RecInitPlus and rPdfInit - depending on which functions you are using, according to kRec/Rec/rPdf function name prefixes.
It is important to call the belonging kRecQuit/RecQuitPlus/rPdfQuit for freeing resources in the end, exactly once for these 3 types of Init calls, in reverse order as usual.
Types

It is assumed that your Java IDE shows type information in-depth, and you as a user of this Java API just have to chose from the public symbols being offered.
The returning agruments of basic types are problemmatic in Java - here it is solved via array of 1 size of that basic type.
E.g. Sample001.java:

long[] timeout = {0};
rc = kRecGetTimeOut(SID,timeout);
...
if (timeout[0] == INFINITE)
...
RECERR RECAPIKRN kRecGetTimeOut(int sid, LPDWORD pTimeOut)
Getting timeout period.

For structs, member values are accessible via the usual setter/getter functions fashion in Java: naming convention is set/get prefix + struct member name. The only exceptions are a few common structs: RECT, SIZE and POINT where helper constructors added by us to avoid excessive use of setters/getters (position of arguments are matching with struct members order).

Enums: here we map safe type of enums (its int value is unused), and unsafe. For the latter one, you want the integer representation in C API (see headers) - to acccess that value, please use the toInt() member function.

Special types that implement java.lang.AutoCloseable:
OutputByteBuffer (Sample007.java)
ProgressMonitorCallback (Sample048.java)
The recommendation of effectively using AutoCloseable (as seen in JavaSamples) causes to avoid running the garbage collector too early.

For the usage of arrays, please look for the given function in JavaSamples as there can be minor differences in how they can be acquired and used.

Resource handling

Where not mentioned explicitly (and no belonging C API function) in this document, objects are freed automatically. E.g. the kRecFree function is available only in C, but doesn't exist in Java, so no need to care about it. However, there are a few ones that exist on the Java API too, and the user has to call these explicitly:

It is important to call these functions before kRecQuit/RecQuitPlus/rPdfQuit, in case have any handle unfreed.

Limitations

These functions are not supported in Java at this moment: