executeQuery() fails with java.lang.NoClassDefFoundError

[hhaensel]

Using a proprietary jdbc driver I experienced a java.lang.NoClassDefFoundError.

It turned out that I could solve it by calling

JDBC.JavaCall.init(["--add-opens=java.base/java.nio=ALL-UNNAMED"])

instead of

JDBC.init()

While the underlying problem should certainly solved by the author of the driver, it could be beneficial to allow for starting options. So what about simply re-exporting JavaCall.init() and including a hint the docs that sometimes starting options might be necessary, e.g.

JDBC.init(["--add-opens=java.base/java.nio=ALL-UNNAMED"])

?

[ExpandingMan]

I haven't used this package in quite a while (I only used it as a "last resort" and thankfully by now there are almost always better alternatives in Julia than using the JVM), but that seems to me like a good idea. We could add

using JavaCall: init

and comment in the docs that JVM command line options can be passed that way.

[hhaensel]

Shall I prepare a PR or do you want to do it?

Just for curiosity: what are the better alternatives? I have to access a proprietary database with either ODBC or JDBC drivers delivered by the maintainer. Currently, the ODBC variant is much slower than JDBC.

[ExpandingMan]

Shall I prepare a PR or do you want to do it?

If you prepare a PR we can get it merged, though I'm not 100% sure at the moment I have the unilateral ability to merge it.

Just for curiosity: what are the better alternatives? I have to access a proprietary database with either ODBC or JDBC drivers delivered by the maintainer. Currently, the ODBC variant is much slower than JDBC.

We increasingly live in a world where, for better or worse, everything is done via HTTP, so there are multiple database systems which I now call that way. Of course, in some cases, such as postgres, there are direct Julia wrappers of specialized libs for those particular databases. If none of that is an option, I try to do ODBC. Indeed that tends to be a pain because it seems vendors care very little about their ODBC drivers, but it's usually better than dealing with the JVM. If you are using some database that's not accessible any other way and their ODBC driver is inexplicably slow, than indeed you might have no other choice, however I'm not sure how expensive getting data between the JVM and Julia is with JavaCall, so it might be worth checking if the end result is really any slower if you haven't already.

[aviks]

I'm happy to merge a PR based on this discussion.

[hhaensel]

Anything missing from my side?

[aviks]

Thanks, no, I just need some free time to review and test the changes.

[hhaensel]

no hurry! Take your time ⌛