JDBC Courier® - Overview

JDBC Courier Features

We can break the feature set into two major pieces: development-time features and runtime features.

JDBC Courier Proxy Type Features

Support for All Standard Data Types

From Byte to Blob, all data types are supported.

Support for All Types of Drivers

From Type 1 to Type 4.

Support for All Modes of Operation

Whether it is over sockets, shared memory, embedded; as long as the Java driver supports it, the C++ and .NET bindings support it

Support for All Types of Statements

PreparedStatement, CallableStatement or the basic Statement are all supported.

Support for JNDI-based Configuration

Configure your C++ or .NET application just like in Java.

As lightweight as Possible

The C++ or .NET proxy types delegate as much as possible to the runtime library to keep the proxy classes as small as possible.

Hi-fidelity Conversion

The generated code exposes Java packages as namespaces, Java fields as fields, Java methods as methods and Java types as types. Use it with very little instruction necessary.

Exception-Safe

The C++ or .NET proxy types can be used in the presence of native exceptions without leaking objects on the Java side. Java exceptions are thrown as native exceptions and can be caught as native exceptions.

Multithread-Ready

The C++ or .NET proxy types can safely and easily be used in multithreaded runtime environments. We do not claim total thread safety because we intentionally did not synchronize write access to the proxy instances for performance reasons.

That being said and assuming you take care of write synchronization, you can safely use proxy objects on multiple threads.

Callback Support

Certain Java interfaces can be used as a callback interfaces. This means that you can implement the Java interface on the native side and have the Java side call your implementation asynchronously (EventListeners, MessageListeners, etc.)

Fewest Possible Surprises

It is impossible to have C++ or .NET proxy types that are totally without surprises. For example, your native language may have different reserved names than Java, so sometimes a valid Java name needs to be changed on the native side to ensure a successful compilation. The C++ or .NET proxy types have extremely few such surprises.

Highly Usable Types

The generated code is just about as usable as the underlying Java types.

Runtime Features

Works With Virtually Any JDBC Provider

No vendor lock-in just because you want to use JDBC from C++ or .NET.

Works With Virtually Any JRE

As long as your Java Runtime Environment supports JNI, it will work in an integrated application. We have tested with JVMs from different vendors, including Oracle, Azul, and IBM, as well as open source implementations like OpenJDK.

Extremely High Performance

Even though JNI has a bad reputation, it is really quite fast. There is inevitable overhead, but you will be very positively surprised by the performance of your integrated application.

Mature Configuration framework

You need to tell your native code where to find the Java parts of the application and how to initialize the JVM or connect to the shared JVM server. You have extreme flexibility, from hardcoding the settings, over using XML config files, all the way to self-configuring DLLs via configuration callbacks.

No Server Necessary

Your finished integrated solution can be totally self-contained without any additional "moving pieces" required.

"xcopy" Deployable

Just copy or move the integrated solution and double-click the executable. If you configured things correctly, it will still work, no registration steps necessary.