Catch the client up to ABI 0.14 by tamnd · Pull Request #17 · tamnd/zu-java

tamnd · 2026-08-24T15:18:05Z

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three additions to zu.h, and both of the ones that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name.

ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one.

zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote, and it is what a corpus runner needs to spell a node as person#1. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. The doc on Value.Node.table() said the C ABI had no such call, which is no longer true, so it now points at Connection.tableName.

Both providers carry both calls. The FFM side gets two more handles in Abi and two overrides in FfmBinding; utf8 is now written over a shared octets helper so the byte path and the string path copy the same way. The JNI side gets two natives, two shims, two lines in the ZU_SYMBOLS table and two in the registration table.

api/surface.txt is every addition and no removal, which is a minor release.

What was run

On a Linux host with JDK 25 and a libzu at the current engine revision, both providers, the whole TCK:

zudb-ffm: 209 tests, 0 failures
zudb-jni: 211 tests, 0 failures

That includes the 9 new BytesTest cases and the 3 new TableNameTest cases on each provider, so what is checked is that the two agree rather than that one of them works. scripts/build-shim.sh builds the C shim clean, and the Java compiles under -Xlint:all -Werror as everything here does.

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three symbols, and both of them that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name. ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one. zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. Both providers carry both calls: the FFM side gets two more handles in Abi and two overrides, the JNI side two natives, two shims and two more lines in the registration table. The TCK covers them, so what is checked is that the two providers agree rather than that one of them works. api/surface.txt is every addition and no removal, which is a minor release.

The header this client vendors is now the engine's header byte for byte, which is what CI has been checking all along and what nothing has satisfied since the check was added. Catching up to the file rather than to the version turned up four exported functions the version does not mention. zu_error_subject_kind, zu_error_subject, zu_error_graph and zu_error_schema arrived in tamnd/zu#581 with ZU_ABI_VERSION left at 0.14, though the two commits before it did bump. So reading the macro was never going to find them and diffing the file was. I have filed that against the engine as tamnd/zu#697. The four carry what ISO 39075 subclause 23.2 asks a diagnostic record to name: which thing the condition is about, what it is called, and the graph and schema the statement was running in. The kind is kept as its own word rather than glued to the front of the name, so asking whether a failure is about a label is one string compared against one word, and an editor that wants to underline the name gets the name with nothing around it. Both providers bind all four, and both TCK suites pass against a real engine: 209 cases through Panama, 211 through JNI, 44 in the core, no failures. This changes the shape of two public members rather than only adding to them. Diagnostic gains four components, so its canonical constructor and its of factory both take fifteen arguments where they took eleven. By the rule in README, a name that changes shape is a major release. Both are the provider-facing way to build a record, so the callers this breaks are provider implementations rather than programs that read rows, but it breaks them and the surface file says so. ZuException gains four accessors and Diagnostic four component readers, and those are additions.

tamnd · 2026-08-24T15:18:05Z

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three additions to zu.h, and both of the ones that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name.

ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one.

zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote, and it is what a corpus runner needs to spell a node as person#1. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. The doc on Value.Node.table() said the C ABI had no such call, which is no longer true, so it now points at Connection.tableName.

Both providers carry both calls. The FFM side gets two more handles in Abi and two overrides in FfmBinding; utf8 is now written over a shared octets helper so the byte path and the string path copy the same way. The JNI side gets two natives, two shims, two lines in the ZU_SYMBOLS table and two in the registration table.

api/surface.txt is every addition and no removal, which is a minor release.

What was run

On a Linux host with JDK 25 and a libzu at the current engine revision, both providers, the whole TCK:

zudb-ffm: 209 tests, 0 failures
zudb-jni: 211 tests, 0 failures

That includes the 9 new BytesTest cases and the 3 new TableNameTest cases on each provider, so what is checked is that the two agree rather than that one of them works. scripts/build-shim.sh builds the C shim clean, and the Java compiles under -Xlint:all -Werror as everything here does.

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three symbols, and both of them that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name. ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one. zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. Both providers carry both calls: the FFM side gets two more handles in Abi and two overrides, the JNI side two natives, two shims and two more lines in the registration table. The TCK covers them, so what is checked is that the two providers agree rather than that one of them works. api/surface.txt is every addition and no removal, which is a minor release.

The header this client vendors is now the engine's header byte for byte, which is what CI has been checking all along and what nothing has satisfied since the check was added. Catching up to the file rather than to the version turned up four exported functions the version does not mention. zu_error_subject_kind, zu_error_subject, zu_error_graph and zu_error_schema arrived in tamnd/zu#581 with ZU_ABI_VERSION left at 0.14, though the two commits before it did bump. So reading the macro was never going to find them and diffing the file was. I have filed that against the engine as tamnd/zu#697. The four carry what ISO 39075 subclause 23.2 asks a diagnostic record to name: which thing the condition is about, what it is called, and the graph and schema the statement was running in. The kind is kept as its own word rather than glued to the front of the name, so asking whether a failure is about a label is one string compared against one word, and an editor that wants to underline the name gets the name with nothing around it. Both providers bind all four, and both TCK suites pass against a real engine: 209 cases through Panama, 211 through JNI, 44 in the core, no failures. This changes the shape of two public members rather than only adding to them. Diagnostic gains four components, so its canonical constructor and its of factory both take fifteen arguments where they took eleven. By the rule in README, a name that changes shape is a major release. Both are the provider-facing way to build a record, so the callers this breaks are provider implementations rather than programs that read rows, but it breaks them and the surface file says so. ZuException gains four accessors and Diagnostic four component readers, and those are additions.

tamnd · 2026-08-24T15:18:05Z

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three additions to zu.h, and both of the ones that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name.

ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one.

zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote, and it is what a corpus runner needs to spell a node as person#1. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. The doc on Value.Node.table() said the C ABI had no such call, which is no longer true, so it now points at Connection.tableName.

Both providers carry both calls. The FFM side gets two more handles in Abi and two overrides in FfmBinding; utf8 is now written over a shared octets helper so the byte path and the string path copy the same way. The JNI side gets two natives, two shims, two lines in the ZU_SYMBOLS table and two in the registration table.

api/surface.txt is every addition and no removal, which is a minor release.

What was run

On a Linux host with JDK 25 and a libzu at the current engine revision, both providers, the whole TCK:

zudb-ffm: 209 tests, 0 failures
zudb-jni: 211 tests, 0 failures

That includes the 9 new BytesTest cases and the 3 new TableNameTest cases on each provider, so what is checked is that the two agree rather than that one of them works. scripts/build-shim.sh builds the C shim clean, and the Java compiles under -Xlint:all -Werror as everything here does.

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three symbols, and both of them that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name. ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one. zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. Both providers carry both calls: the FFM side gets two more handles in Abi and two overrides, the JNI side two natives, two shims and two more lines in the registration table. The TCK covers them, so what is checked is that the two providers agree rather than that one of them works. api/surface.txt is every addition and no removal, which is a minor release.

The header this client vendors is now the engine's header byte for byte, which is what CI has been checking all along and what nothing has satisfied since the check was added. Catching up to the file rather than to the version turned up four exported functions the version does not mention. zu_error_subject_kind, zu_error_subject, zu_error_graph and zu_error_schema arrived in tamnd/zu#581 with ZU_ABI_VERSION left at 0.14, though the two commits before it did bump. So reading the macro was never going to find them and diffing the file was. I have filed that against the engine as tamnd/zu#697. The four carry what ISO 39075 subclause 23.2 asks a diagnostic record to name: which thing the condition is about, what it is called, and the graph and schema the statement was running in. The kind is kept as its own word rather than glued to the front of the name, so asking whether a failure is about a label is one string compared against one word, and an editor that wants to underline the name gets the name with nothing around it. Both providers bind all four, and both TCK suites pass against a real engine: 209 cases through Panama, 211 through JNI, 44 in the core, no failures. This changes the shape of two public members rather than only adding to them. Diagnostic gains four components, so its canonical constructor and its of factory both take fifteen arguments where they took eleven. By the rule in README, a name that changes shape is a major release. Both are the provider-facing way to build a record, so the callers this breaks are provider implementations rather than programs that read rows, but it breaks them and the surface file says so. ZuException gains four accessors and Diagnostic four component readers, and those are additions.

tamnd · 2026-08-24T15:18:05Z

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three additions to zu.h, and both of the ones that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name.

ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one.

zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote, and it is what a corpus runner needs to spell a node as person#1. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. The doc on Value.Node.table() said the C ABI had no such call, which is no longer true, so it now points at Connection.tableName.

Both providers carry both calls. The FFM side gets two more handles in Abi and two overrides in FfmBinding; utf8 is now written over a shared octets helper so the byte path and the string path copy the same way. The JNI side gets two natives, two shims, two lines in the ZU_SYMBOLS table and two in the registration table.

api/surface.txt is every addition and no removal, which is a minor release.

What was run

On a Linux host with JDK 25 and a libzu at the current engine revision, both providers, the whole TCK:

zudb-ffm: 209 tests, 0 failures
zudb-jni: 211 tests, 0 failures

That includes the 9 new BytesTest cases and the 3 new TableNameTest cases on each provider, so what is checked is that the two agree rather than that one of them works. scripts/build-shim.sh builds the C shim clean, and the Java compiles under -Xlint:all -Werror as everything here does.

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three symbols, and both of them that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name. ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one. zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. Both providers carry both calls: the FFM side gets two more handles in Abi and two overrides, the JNI side two natives, two shims and two more lines in the registration table. The TCK covers them, so what is checked is that the two providers agree rather than that one of them works. api/surface.txt is every addition and no removal, which is a minor release.

The header this client vendors is now the engine's header byte for byte, which is what CI has been checking all along and what nothing has satisfied since the check was added. Catching up to the file rather than to the version turned up four exported functions the version does not mention. zu_error_subject_kind, zu_error_subject, zu_error_graph and zu_error_schema arrived in tamnd/zu#581 with ZU_ABI_VERSION left at 0.14, though the two commits before it did bump. So reading the macro was never going to find them and diffing the file was. I have filed that against the engine as tamnd/zu#697. The four carry what ISO 39075 subclause 23.2 asks a diagnostic record to name: which thing the condition is about, what it is called, and the graph and schema the statement was running in. The kind is kept as its own word rather than glued to the front of the name, so asking whether a failure is about a label is one string compared against one word, and an editor that wants to underline the name gets the name with nothing around it. Both providers bind all four, and both TCK suites pass against a real engine: 209 cases through Panama, 211 through JNI, 44 in the core, no failures. This changes the shape of two public members rather than only adding to them. Diagnostic gains four components, so its canonical constructor and its of factory both take fifteen arguments where they took eleven. By the rule in README, a name that changes shape is a major release. Both are the provider-facing way to build a record, so the callers this breaks are provider implementations rather than programs that read rows, but it breaks them and the surface file says so. ZuException gains four accessors and Diagnostic four component readers, and those are additions.

tamnd · 2026-08-24T15:18:05Z

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three additions to zu.h, and both of the ones that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name.

ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one.

zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote, and it is what a corpus runner needs to spell a node as person#1. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. The doc on Value.Node.table() said the C ABI had no such call, which is no longer true, so it now points at Connection.tableName.

Both providers carry both calls. The FFM side gets two more handles in Abi and two overrides in FfmBinding; utf8 is now written over a shared octets helper so the byte path and the string path copy the same way. The JNI side gets two natives, two shims, two lines in the ZU_SYMBOLS table and two in the registration table.

api/surface.txt is every addition and no removal, which is a minor release.

What was run

On a Linux host with JDK 25 and a libzu at the current engine revision, both providers, the whole TCK:

zudb-ffm: 209 tests, 0 failures
zudb-jni: 211 tests, 0 failures

That includes the 9 new BytesTest cases and the 3 new TableNameTest cases on each provider, so what is checked is that the two agree rather than that one of them works. scripts/build-shim.sh builds the C shim clean, and the Java compiles under -Xlint:all -Werror as everything here does.

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three symbols, and both of them that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name. ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one. zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. Both providers carry both calls: the FFM side gets two more handles in Abi and two overrides, the JNI side two natives, two shims and two more lines in the registration table. The TCK covers them, so what is checked is that the two providers agree rather than that one of them works. api/surface.txt is every addition and no removal, which is a minor release.

The header this client vendors is now the engine's header byte for byte, which is what CI has been checking all along and what nothing has satisfied since the check was added. Catching up to the file rather than to the version turned up four exported functions the version does not mention. zu_error_subject_kind, zu_error_subject, zu_error_graph and zu_error_schema arrived in tamnd/zu#581 with ZU_ABI_VERSION left at 0.14, though the two commits before it did bump. So reading the macro was never going to find them and diffing the file was. I have filed that against the engine as tamnd/zu#697. The four carry what ISO 39075 subclause 23.2 asks a diagnostic record to name: which thing the condition is about, what it is called, and the graph and schema the statement was running in. The kind is kept as its own word rather than glued to the front of the name, so asking whether a failure is about a label is one string compared against one word, and an editor that wants to underline the name gets the name with nothing around it. Both providers bind all four, and both TCK suites pass against a real engine: 209 cases through Panama, 211 through JNI, 44 in the core, no failures. This changes the shape of two public members rather than only adding to them. Diagnostic gains four components, so its canonical constructor and its of factory both take fifteen arguments where they took eleven. By the rule in README, a name that changes shape is a major release. Both are the provider-facing way to build a record, so the callers this breaks are provider implementations rather than programs that read rows, but it breaks them and the surface file says so. ZuException gains four accessors and Diagnostic four component readers, and those are additions.

tamnd · 2026-08-24T15:18:05Z

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three additions to zu.h, and both of the ones that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name.

ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one.

zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote, and it is what a corpus runner needs to spell a node as person#1. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. The doc on Value.Node.table() said the C ABI had no such call, which is no longer true, so it now points at Connection.tableName.

Both providers carry both calls. The FFM side gets two more handles in Abi and two overrides in FfmBinding; utf8 is now written over a shared octets helper so the byte path and the string path copy the same way. The JNI side gets two natives, two shims, two lines in the ZU_SYMBOLS table and two in the registration table.

api/surface.txt is every addition and no removal, which is a minor release.

What was run

On a Linux host with JDK 25 and a libzu at the current engine revision, both providers, the whole TCK:

zudb-ffm: 209 tests, 0 failures
zudb-jni: 211 tests, 0 failures

That includes the 9 new BytesTest cases and the 3 new TableNameTest cases on each provider, so what is checked is that the two agree rather than that one of them works. scripts/build-shim.sh builds the C shim clean, and the Java compiles under -Xlint:all -Werror as everything here does.

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three symbols, and both of them that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name. ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one. zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. Both providers carry both calls: the FFM side gets two more handles in Abi and two overrides, the JNI side two natives, two shims and two more lines in the registration table. The TCK covers them, so what is checked is that the two providers agree rather than that one of them works. api/surface.txt is every addition and no removal, which is a minor release.

The header this client vendors is now the engine's header byte for byte, which is what CI has been checking all along and what nothing has satisfied since the check was added. Catching up to the file rather than to the version turned up four exported functions the version does not mention. zu_error_subject_kind, zu_error_subject, zu_error_graph and zu_error_schema arrived in tamnd/zu#581 with ZU_ABI_VERSION left at 0.14, though the two commits before it did bump. So reading the macro was never going to find them and diffing the file was. I have filed that against the engine as tamnd/zu#697. The four carry what ISO 39075 subclause 23.2 asks a diagnostic record to name: which thing the condition is about, what it is called, and the graph and schema the statement was running in. The kind is kept as its own word rather than glued to the front of the name, so asking whether a failure is about a label is one string compared against one word, and an editor that wants to underline the name gets the name with nothing around it. Both providers bind all four, and both TCK suites pass against a real engine: 209 cases through Panama, 211 through JNI, 44 in the core, no failures. This changes the shape of two public members rather than only adding to them. Diagnostic gains four components, so its canonical constructor and its of factory both take fifteen arguments where they took eleven. By the rule in README, a name that changes shape is a major release. Both are the provider-facing way to build a record, so the callers this breaks are provider implementations rather than programs that read rows, but it breaks them and the surface file says so. ZuException gains four accessors and Diagnostic four component readers, and those are additions.

tamnd · 2026-08-24T15:18:05Z

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three additions to zu.h, and both of the ones that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name.

ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one.

zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote, and it is what a corpus runner needs to spell a node as person#1. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. The doc on Value.Node.table() said the C ABI had no such call, which is no longer true, so it now points at Connection.tableName.

Both providers carry both calls. The FFM side gets two more handles in Abi and two overrides in FfmBinding; utf8 is now written over a shared octets helper so the byte path and the string path copy the same way. The JNI side gets two natives, two shims, two lines in the ZU_SYMBOLS table and two in the registration table.

api/surface.txt is every addition and no removal, which is a minor release.

What was run

On a Linux host with JDK 25 and a libzu at the current engine revision, both providers, the whole TCK:

zudb-ffm: 209 tests, 0 failures
zudb-jni: 211 tests, 0 failures

That includes the 9 new BytesTest cases and the 3 new TableNameTest cases on each provider, so what is checked is that the two agree rather than that one of them works. scripts/build-shim.sh builds the C shim clean, and the Java compiles under -Xlint:all -Werror as everything here does.

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three symbols, and both of them that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name. ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one. zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. Both providers carry both calls: the FFM side gets two more handles in Abi and two overrides, the JNI side two natives, two shims and two more lines in the registration table. The TCK covers them, so what is checked is that the two providers agree rather than that one of them works. api/surface.txt is every addition and no removal, which is a minor release.

The header this client vendors is now the engine's header byte for byte, which is what CI has been checking all along and what nothing has satisfied since the check was added. Catching up to the file rather than to the version turned up four exported functions the version does not mention. zu_error_subject_kind, zu_error_subject, zu_error_graph and zu_error_schema arrived in tamnd/zu#581 with ZU_ABI_VERSION left at 0.14, though the two commits before it did bump. So reading the macro was never going to find them and diffing the file was. I have filed that against the engine as tamnd/zu#697. The four carry what ISO 39075 subclause 23.2 asks a diagnostic record to name: which thing the condition is about, what it is called, and the graph and schema the statement was running in. The kind is kept as its own word rather than glued to the front of the name, so asking whether a failure is about a label is one string compared against one word, and an editor that wants to underline the name gets the name with nothing around it. Both providers bind all four, and both TCK suites pass against a real engine: 209 cases through Panama, 211 through JNI, 44 in the core, no failures. This changes the shape of two public members rather than only adding to them. Diagnostic gains four components, so its canonical constructor and its of factory both take fifteen arguments where they took eleven. By the rule in README, a name that changes shape is a major release. Both are the provider-facing way to build a record, so the callers this breaks are provider implementations rather than programs that read rows, but it breaks them and the surface file says so. ZuException gains four accessors and Diagnostic four component readers, and those are additions.

tamnd · 2026-08-24T15:18:05Z

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three additions to zu.h, and both of the ones that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name.

ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one.

zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote, and it is what a corpus runner needs to spell a node as person#1. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. The doc on Value.Node.table() said the C ABI had no such call, which is no longer true, so it now points at Connection.tableName.

Both providers carry both calls. The FFM side gets two more handles in Abi and two overrides in FfmBinding; utf8 is now written over a shared octets helper so the byte path and the string path copy the same way. The JNI side gets two natives, two shims, two lines in the ZU_SYMBOLS table and two in the registration table.

api/surface.txt is every addition and no removal, which is a minor release.

What was run

On a Linux host with JDK 25 and a libzu at the current engine revision, both providers, the whole TCK:

zudb-ffm: 209 tests, 0 failures
zudb-jni: 211 tests, 0 failures

That includes the 9 new BytesTest cases and the 3 new TableNameTest cases on each provider, so what is checked is that the two agree rather than that one of them works. scripts/build-shim.sh builds the C shim clean, and the Java compiles under -Xlint:all -Werror as everything here does.

This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three symbols, and both of them that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name. ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one. zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. Both providers carry both calls: the FFM side gets two more handles in Abi and two overrides, the JNI side two natives, two shims and two more lines in the registration table. The TCK covers them, so what is checked is that the two providers agree rather than that one of them works. api/surface.txt is every addition and no removal, which is a minor release.

The header this client vendors is now the engine's header byte for byte, which is what CI has been checking all along and what nothing has satisfied since the check was added. Catching up to the file rather than to the version turned up four exported functions the version does not mention. zu_error_subject_kind, zu_error_subject, zu_error_graph and zu_error_schema arrived in tamnd/zu#581 with ZU_ABI_VERSION left at 0.14, though the two commits before it did bump. So reading the macro was never going to find them and diffing the file was. I have filed that against the engine as tamnd/zu#697. The four carry what ISO 39075 subclause 23.2 asks a diagnostic record to name: which thing the condition is about, what it is called, and the graph and schema the statement was running in. The kind is kept as its own word rather than glued to the front of the name, so asking whether a failure is about a label is one string compared against one word, and an editor that wants to underline the name gets the name with nothing around it. Both providers bind all four, and both TCK suites pass against a real engine: 209 cases through Panama, 211 through JNI, 44 in the core, no failures. This changes the shape of two public members rather than only adding to them. Diagnostic gains four components, so its canonical constructor and its of factory both take fifteen arguments where they took eleven. By the rule in README, a name that changes shape is a major release. Both are the provider-facing way to build a record, so the callers this breaks are provider implementations rather than programs that read rows, but it breaks them and the surface file says so. ZuException gains four accessors and Diagnostic four component readers, and those are additions.