Universal Data Access Technology Blog

Life after sun.jdbc.odbc.JdbcOdbcDriver

Thu, 04 Jun 2015 21:12:19 GMT

In the beginning...

When Sun originally released Java 1.0, there were no JDBC drivers -- there wasn't even a JDBC.

Data access came in Java 2.0, as JDBC 1.0, but there were very few JDBC drivers from any source, as would be expected with any new technology -- but the ODBC ecosystem (itself then at only v2.0) was going strong.

Sun recognized that Java wouldn't have as much uptake without a functional data access solution -- so they produced and bundled the original Type 1 JDBC-ODBC Bridge Driver, sun.jdbc.odbc.JdbcOdbcDriver, but from the very beginning, they warned that users "should use the JDBC-ODBC Bridge only for experimental prototyping or when you have no other driver available."

That bundled JDBC-ODBC Bridge was (and always remained) single-threaded, and though it received some other updates along the way, it only ever supported a subset of JDBC 2.0 and later. Sun (and later Oracle) recommended that users employ "a pure Java JDBC technology-enabled driver, type 3 or 4, in order to get all of the benefits of the Java programming language and the JDBC API."

Where does OpenLink Software come in?

Even in the early days of JDBC, we saw that there would not always be an available JDBC driver for a given target data source -- but the numbers of ODBC drivers were rapidly increasing, supporting every major and many minor DBMS and other data sources. We saw a need for an enterprise-grade, non-experimental Bridge solution, with full support for the JDBC API.

We delivered this first as our Type 3 Multi-Tier solution, bridging from JDBC in one environment (typically a UNIX-like OS) to ODBC in another (most often, Microsoft Windows).

Type 3 Enterprise Edition (Multi-Tier) Architecture Diagram
(click to enlarge)

Soon afterward, we released our first Type 1 Single-Tier solution, first for Windows, but quickly also supporting Linux, Mac OS X, Solaris, AIX, HP-UX, and other UNIX-like OS, through our own iODBC driver manager -- which was itself helping to expand the ODBC ecosystem far beyond its birthplace on Windows.

Type 1 Lite Edition (Single-Tier) Architecture Diagram
(click to enlarge)

Why is Java 8 so special?

Sun long warned that the JRE-bundled Bridge was transitional, and Oracle confirmed immediately upon acquisition that it would "be removed in JDK 8. In addition, Oracle does not support the JDBC-ODBC Bridge." Java 8 is now in full release, and indeed, the venerable sun.jdbc.odbc.JdbcOdbcDriver is no longer present, as evidenced by the scary looking error --

java.lang.ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver
    at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:30
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:259)

Any Java users or applications relying on ODBC connections and also needing the security and other improvements found in Java 8 are left high and dry... Or would be, but for OpenLink Software.

Our JDBC-to-ODBC Bridge, in both Type 1 and Type 3 forms, has been available and regularly updated since its original release for JDBC 1. Fully multi-threaded since Java Runtime Environments (JREs) could handle such, we have also kept pace with the JDBC API -- now at JDBC 4.2, in 2015's Java 8 a/k/a JDK/JVM/JRE 1.8 -- and maintained compatibility with the also-evolving ODBC API, now at 3.8.

Especially important for the modern world, our solutions support both 64-bit and 32-bit environments, including both 64-bit JVMs and ODBC drivers, and our Type 3 solutions can even bridge between these, whether you have a 64-bit JVM and need to connect to a 32-bit ODBC driver, or you have a 32-bit JVM and need to connect to a 64-bit ODBC driver.

As always, our solutions are available for immediate download, with a free two-week trial license provided alongside. We encourage pre-purchase installation, configuration, and testing, with support provided through our web-based Support Forums and even free up-and-running Support Cases. Once you've confirmed the driver works for you, entry level and special offer licenses may be purchased online or through our Sales Team; these as well as custom license configurations or partnership (IBP, ISV, VAR, OEM, etc.) arrangements are always available by direct contact.

DataSpaces Bulletin: December issue now online!

Tue, 09 Dec 2008 18:09:00 GMT

The highly anticipated December 2008 issue of the DataSpaces Bulletin is now available!

This month's DataSpaces contains material of interest to the Virtuoso developer and UDA user community alike —

Introduction to Virtuoso Universal Server (Cloud Edition).
Links to Virtuoso and Linked Data mailing lists.
UDA license management tips and tricks.

Creating RSS Using SQLX

Tue, 11 Nov 2003 23:33:50 GMT

Here is a practical example of how to create RSS on the fly from SQL data sources leveraging Virtuoso 3.2's SQLX implementation.

This is further illuminates the content of my earlier post on this subject.

XML Development Hindered by Lack of Conformity to Data Connectivity Standards ?

Tue, 11 Nov 2003 23:14:55 GMT

I've just read an

HOWTO: Apache-PHP-ODBC on Mac OS X

Fri, 24 Oct 2003 15:39:28 GMT

There is a new HOWTO document that addresses an area of frequent confusion on Mac OS X, which is how do you build PHP with an ODBC data access layer binding ( iODBC variant) using Mac OS X Frameworks as opposed to Darwin Shared Libraries.

A Virtuoso of a Server

Thu, 23 Oct 2003 21:58:31 GMT

NETWORK WORLD NEWSLETTER: MARK GIBBS ON WEB APPLICATIONS

Today's focus: A Virtuoso of a server

By Mark Gibbs

One of the bigger drags of Web applications development is that building a system of even modest complexity is a lot like herding cats - you need a database, an applications server, an XML engine, etc., etc. And as they all come from different vendors you are faced with solving the constellation of integration issues that inevitably arise.

If you are lucky, your integration results in a smoothly functioning system. If not, you have a lot of spare parts flying in loose formation with the risk of a crash and burn at any moment.

An alternative is to look for all of these features and services in a single package but you'll find few choices in this arena.

One that is available and looks very promising is OpenLink's Virtuoso (see links below).

Virtuoso is described as a cross platform (runs on Windows, all Unix flavors, Linux, and Mac OS X) universal server that provides databases, XML services, a Web application server and supporting services all in a single package.

OpenLink's list of supported standards is impressive and includes .Net, Mono, J2EE, XML Web Services (Simple Object Application Protocol, Web Services Description Language, WS-Security, Universal Description, Discovery and Integration), XML, XPath, XQuery, XSL-T, WebDav, HTTP, SMTP, LDAP, POP3, SQL-92, ODBC, JDBC and OLE-DB.

Virtuoso provides an HTTP-compliant Web Server; native XML document creation, storage and management; a Web services platform for creation, hosting and consumption of Web services; content replication and synchronization services; free text index server, mail delivery and storage and an NNTP server.

Another interesting feature is that with Virtuoso you can create Web services from existing SQL Stored Procedures, Java classes,

C++ classes, and 'C' functions as well as create dynamic XML

documents from ODBC and JDBC data sources.

This is an enormous product and implies a serious commitment on the part of adopters due to its scope and range of services.

Virtuoso is enormous by virtue of its architectural ambitions, but actual disk requirements are

MySQL-ODBC Bridge SDK

Thu, 02 Oct 2003 18:20:42 GMT

What Is This?

The MySQL-ODBC SDK enables you to make MySQL specific applications database independent via ODBC without wholesale re-writes of your MySQL specific application code. Thus, applications that are written directly to the MySQL Call Level Interface now end up being database independent via ODBC, and usable against any ODBC accessible database (including MySQL).

Why Is It Important?

The Open-Source community is rapidly producing innovative applications and in many cases these applications sit atop relational database management systems. Traditionally and historically, the tendency has been to look to MySQL as the default relational database service for Open Source Applications (the "M" in LAMP) which is unfortunately retrogressive since the concept of database independence has long been addressed industry wide via APIs such as ODBC, JDBC, OLE DB, and more recently ADO.NET.

In some case the existence of these APIs has been unknown to Open Source developers prior to application development, and in other cases the complexity of a port from the MySQL API to ODBC ends up being too difficult. There are numerous reasons why you can't mandate MySQL or any other database engine for that matter to every potential user of an Open Source database centric application:

Compromises freedom of choice ("Freedom of Choice" is a central theme of the Open Source movement and concept)
Database vendor lock-in reduces the deployment scope of your application, and it also potentially impedes functionality growth (what happens when the underlying database lacks the functionality that you desire? And cannot or will not deliver an implementation within your time-frame?)
Cost-Effectiveness is an Open Source value proposition main stay, so asking potential users to acquire yet another database (the real costs aren't $0.00 as resources will be required for administration, installation, configuration etc.) when functional ODBC accessible relational databases exist in house is simply contradictory at the very least.

ODBC as a concept has always been designed to be database-independent; iODBC as an Open Source project was devised to ensure platform neutrality for ODBC (just as Mono is pursuing the same goals re. .NET). When you write an application using the ODBC API database interchangeablity becomes a reality (the worst thing that can happen to you is a dysfunctional driver which is replaceable). Read on..