That is not at all clear to me.  As I pointed out, both designs involve three processes: the client, the server, and an intermediate program involving Java.

The bespoke solution requires designing (or stealing) a SQL protocol for the client-to-intermediate connection  If it isn't either the Postgres or Widenius wire protocol, it will also require a client in portable Scheme.  Finally, a substantial intermediate program in Kawa must be written and possibly maintained by us or our successors that speaks the SQL protocol and makes JDBC calls.  I've looked at sample Kawa programs with heavy JVM interface, and they look a lot like Java programs with Scheme syntax.  At install time, the user must install Kawa, our intermediate Kawa program, and the client library if any.

WIth the Connect solution, the amortized implementation effort is zero.  The Widenius protocol already exists.  The Widenius client is already part of the project's primary goals.  Connect dynamically links to the system JVM and does everything the Kawa program would have to do.  The user needs to install MariaDB and Connect.

(In either case, a JVM would need to be installed if not already present.)

John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
And through this revolting graveyard of the universe the muffled,
maddening beating of drums, and thin, monotonous whine of blasphemous
flutes from inconceivable, unlighted chambers beyond Time; the
detestable pounding and piping whereunto dance slowly, awkwardly, and
absurdly the gigantic tenebrous ultimate gods --the blind, voiceless,
mindless gargoyles whose soul is Nyarlathotep. (Lovecraft)