JDBC Courier Introduction
You usually find JDBC Courier on-line because you have been given the task to find a driver that allows your C++ or .NET application to connecto to your enterprise or embedded database. You found a bunch of native drivers that are buggy or not feature complete or have a high license cost.
Then you come across JDBC Courier. It claims to be feature-complete. It claims to be fast. It claims to work with any JDBC driver, including the free ones! Could this really be true or are these just inflated vendor claims?
Well, it really is true.
JDBC Courier was first released in 2020, though customers had used JunC++ion and JuggerNET to generate similar solutions for several years before.
How It Works
We used our JunC++ion and JuggerNET products to generate C++ and .NET proxy types for the complete JDBC API and some assorted Java support types. Your developers code to these types, which are provided to you in the form of libraries/assemblies. At runtime, the proxy types delegate in-process to the underlying Java types.
Just to stress this fact: our code generators generate C++ or .NET bindings for Java types, they do not translate the Java types to native code. As the proxy types delegate to Java, you still need a regular JDBC driver to perform the actual database access, JDBC Courier simply provides an easy-to-use C++ and .NET gateway, both at development- and at runtime. JDBC Courier is essentially a high-quality shim on top of JDBC.
Which JDBC Drivers Are Supported
Any spec-compliant JDBC implementation is supported. If the JDBC implementation does not support a specific JDBC feature due to bugs or feature incompleteness, the C++ and .NET types will of course also not support it. Anything that the Java implementation provides via the standard JDBC API is supported.
What's Missing?
The only things that are missing are vendor-specific database extensions. We stuck to exposing the core JDBC specification and Java types that are required to working with the core JDBC specification. We added in a generous amount of Java utility types but vendor specific extensions are explicitly not part of the distribution.
If you need to use a vendor-specific database API from your C++ or .NET application, you can use JunC++ion or JuggerNET to create a provider-specific version of JMS Courier that includes the proxy types for your vendor's API extensions. We will help you with the customization if you give us a call.
Reliability, Reliability, Reliability...
The fact that the overwhelming majority of the code you will use as part of JDBC Courier is computer-generated has some fairly dramatic consequences: while it does not guarantee the absence of bugs, it guarantees that there are only three kinds of bugs:
- Systematic Bugs in the Generated Code
The chance that someone already stumbled over this kind of bug in the past is very large. We have a fairly large and active user base for all our products, so chances are that if there were a bug at all, it would be a fairly obscure one. To provide a now fixed code generator problem from the past as an example of such a systematic bug, here's a bug description: "two-deep nested inner interfaces don't generate correctly."
No such bugs have affected JDBC Courier... ever.
- Bugs in the Runtime Library
We've had our share of these over the years, but the majority tended to be relatively trivial and the last one was encountered in 2016. You will benefit from not just the JDBC Courier user base filing bugs against this module but from all JunC++ion and JuggerNET users as well! The runtime library is a shared component between all three products.
- Bugs in the Underlying JDBC Implementation (at Runtime)
You will be using some vendor's JDBC driver at runtime, and that implementation will undoubtedly have some bugs. Your C++ and .NET clients will encounter exactly the same bugs that your Java clients encounter because they will be using the same Java implementation.
Why do we spend so much time talking about bugs? JDBC is an enterprise database framework, so in all likelihood your C++ or .NET applications have pretty high reliability and performance requirements. We would never have dared publishing JDBC Courier if we had had to handwrite or even just manually touch the generated types.
By virtue of being generated, JDBC Courier has a pretty stellar track record when it comes to reliability!