you're reading...


Crazy App Idea: JDBC on Cocoa

Cocoa Coffee Beans DatabaseEver tried to access an SQL database from your Mac app? I mean direct connection to a real database – not just embedding SQLite inside your app. The biggest problem is how to make your app understands the proprietary byte protocols spoken by the remote databases. On top of that you still need to make sure that the SQL dialect that you write can be understood by the database. What a double whammy problem.

How about ODBC? Macs are certified Unix boxes nowadays and since ODBC is available for Unix, it should also available on Macs.  But Unix ODBC only provides source-level compatibility and thus often requires recompilation of the database drivers’ source code. Unfortunately many database vendors doesn’t provide source code of their ODBC drivers.

There are a number of third-party ODBC driver providers that sells Mac drivers. But how far can you trust these third parties? How complete are their implementations? What about some edge cases that have been solved by the “original” drivers but doesn’t trickle down to third-party drivers? Worse, what if nobody provides a Mac-compatible ODBC driver for your chosen database?

Then How?

So I have this crazy idea: why not use JDBC instead? I couldn’t think any production-quality SQL database that doesn’t have a JDBC driver. Since it’s pure Java, these drivers should also runs on Macs unchanged. Most of the app will still be written in Cocoa to provide the superior user experience and performance that we’ve been accustomed to – but it uses the Java Virtual Machine (JVM) as a library just to run the JDBC drivers to talk to their respective SQL databases.

In essence, your app uses the Java Native Interface (JNI) and instantiate an embedded JVM within your app using the JNI_CreateJavaVM function. Then it loads the JDBC driver and uses it like any Java program would – but you’ll be calling those Java methods from Objective-C. This article on calling Java functions from C should get you started on the right path.


  • Guaranteed 100% compatibility with the database – since the drivers are written by the vendors themselves.
  • Retains all the great performance and integrations of a native Cocoa app.
  • Could prohibit your app from entering the Mac App Store.
  • The JVM may add quite a bit to your app’s VM size – my guesstimate is 32-64MB of address space may be taken by the Java Virtual Machine. 

Softening the Blow

There are methods that you can do to alleviate the Mac App Store issue:
  • Distribute the JVM-dependent component separately. You can package that part of the app as a loadable bundle that you provide in your own site for users to download. Then the app can load this bundle just like a “plug-in” to enable JDBC access. I suppose BBEdit follows a similar approach to this where they have some components that users need to download to make the Mac App Store version of BBEdit get most of the features of its direct-purchase twin sister.
  • Translate the JDBC drivers into native code. You can use tools like Gnu Compiler for Java (GCJ) to natively compile your chosen drivers then package them with your app. This approach may also reduce your app’s footprint since it doesn’t need the JVM any longer and simply replaced with GCJ’s run-time libraries. Alternatively, your app can embed GCJ and let it convert any JDBC driver to native code that your app can use – just make sure you don’t link to GCJ and only call it as an external executable, so that the GPL doesn’t infect your code.
  • Embed the JVM as part of your app. Even Oracle said this is the recommended approach to distribute your Java-based app to the Mac App Store (as of this writing).

Is it Radical?

Yes it is… NOT! I believe CyberDuck (the open source Mac FTP Client) also uses this approach. They use Java-based Apache Commons Net as part of their networking code. I found out about it from the Java exceptions dumped in their log messages in the Console.

What about ODBC-JDBC bridge? Yes it may be an option. OpenLink provides a Mac version of their ODBC-JDBC bridge. But remember the law of leaky abstractions – you’re adding yet another 3rd party component between your app and the database. This is yet another component that your user needs to configure and could cause havoc it not set up properly. Not to mention that Apple practically deprecated ODBC since they stopped distributing ODBC Administrator since Snow Leopard.

So there you have it – I’m pondering to do a project on this if there’s significant interest to it.

That’s all for now. Take care!

Do you enjoy this post? Enter your e-mail address below to receive articles like this one in your mailbox.

Free Updates!

Learn how to grow your indie business while keeping your day job.



Keep updated!

Don't miss out on new articles!