IKVM does 100%. But it is not a code translator. Byte code to IL. We pass the full JDK test suite, for JDK8 anyways.
So you can kind of forget I'm using it, and pretend I'm just asking about Java, but I've got a custom driver framework that isn't JDBC, so I'm trying to do what Calcites JDBC driver does without JDBC. The question is where in Calcite does the JDBC end and the Calcite begin, if you get my drift. Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Julian Hyde <[email protected]> Sent: Saturday, October 18, 2025 9:04:56 PM To: [email protected] <[email protected]> Subject: Re: Calcite and !JDBC It’s no accident that the comment at the top of CalcitePrepareImpl is “Shit just got real”. It’s the coordinator of the planning process, so needs to deal with both expression algebra and dynamics (generating a statement id, so that the statement can hook into resource and lifecycle management). It’s hard to cut this Gordian knot. Can you mock the JDBC bits, or map them onto .NET concepts? (They’re not too dissimilar… both evolved from ODBC.) If I were taking on this project, and using an automated translation tool like IKVM, I would make a clone of the Calcite Java code and refactor it a bit. I don’t know IKVM but I suspect that it can do 90% or 99% but struggles with the last 1%. Once you’ve discovered which refactorings made it work, you’ve discovered which are the right cuts in the Gordian knot, and can perhaps contribute those back to Calcite. Julian > On Oct 17, 2025, at 9:09 AM, Jerome Haltom <[email protected]> wrote: > > Hello. > > I am doing an interesting project (or so I think) using Calcite. I am > attempting to write a .NET library that makes use of Calcite. The goal being > to expose the Calcite operations one can normally do under JDBC in a nice > .NET-like API surface using System.Data. So, a .NET class, > Apache.Calcite.Data.CalciteConnection, which implements the .NET > driver/connection model, but ultimately does the same thing the Calcite JDBC > driver does. A nice clean .NET-like API surface that uses Calcite under the > covers. I am doing this with IKVM (which is a JVM "implementation" that > converts Java bytecode to .NET IL). > > I have no problem fully using all the Calcite classes this way. Including the > JDBC driver, etc. Everything works perfectly fine. So, my question is not > about this translation layer, or this JVM implementation, or anything like > that. I only mention it to provide context to my question. > > My question is about how 'deep' into the core Calcite code the JDBC stuff > extends. > > I started this effort out by figuring I would mostly just need to rewrite a > more appropriate version of org.apache.calcite.jdbc, that ultimately surfaced > a .NET API but used all the same Calcite internals. But the more I dig into > that, the more I find a few JDBC-isms that have snuck outside that package. > For instance, org.apache.calcite.jdbc.CalciteScema is a big class. Doing > quite a bit of work. And it's referenced by org.apache.calcite.prepare. And > it's also accessed by the SqlSpatialTypeOperatorTable. And a few things in > sql.validate. And some stuff in calcite.schema.impl.ViewTable, materialize, > etc. > > Basically, JDBC extends deeper into Calcite than I had expected. So, I'm no > longer just confronted with writing a new Connection-like implementation, but > with new implementations of a number of other classes that seem pretty > unrelated to JDBC itself. > > So, then I think, okay. I may abandon that plan and instead preserve and not > rewrite a class like CalciteSchema. But use the existing jdbc.CalciteSchema > in my new CalciteConnection implementation. The namespaces/packages won't be > as clear to users: they'll be creating jdbc.CalciteSchemas and adding them to > Apache.Cacite.Data.CalciteConnections. Bit funny looking. But should work. > > So, how much of jdbc.* can I preserve, and how much is actually tied to JDBC? > CalciteSchema seems pretty clear. But, CalcitePrepare does not! > CalcitePrepare has a few things in it, like CalciteSignature, which extends > an Avatica class, Meta.Signature, and expects a list of AvaticaParameters. > And this is very much JDBC-tied. But I need CalcitePrepare because of > materialize/Lattice and all that. > > So, it looks like bunch of Core stuff is tied into CalcitePrepare. But I > can't make use it since it relies on having a bunch of Avatica JDBC specific > stuff exposed. Which a non-JDBC access method wouldn't have. > > Any recommendations here? Ignore my .NET related context if you want, and > pretend I'm writing a driver for some other driver framework that just has no > support for JDBC-like stuff. > >
