Parameters processing API#4
Merged
Merged
Conversation
parameters_get / parameters_insert / parameters_remove / parameters_is_well_formed: thin #[prebindgen] wrappers over zenoh::query::Parameters. They give downstream bindings a native oracle to correspondence-test pure-JVM/pure-target parameter parsing against (the production parse stays on the binding side with zero FFI crossings), and mirror zenoh-c's parameter-utility surface. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This was referenced Jul 17, 2026
…Parameters
Rework the parameters functions from a verification-only framing into
regular zenoh-flat API, in line with the crate's charter: cover the main
zenoh API in translatable form, usable from any language binding for real
parameter processing (zenoh-flat-c wraps them directly; the JVM bindings
reimplement the semantics in pure Kotlin because crossing JNI per string
operation is expensive — a JNI peculiarity, not a design choice — and verify
the correspondence against these functions in tests).
Move the functions to a dedicated src/base/query/parameters.rs module and
complete the struct mirror: parameters_values ('|'-separated value list),
parameters_contains_key, and parameters_extend join get/insert/remove/
is_well_formed. insert/remove return the resulting string; the replaced
value, when needed, is parameters_get before mutating (the Rust tuple return
does not translate).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
milyin
changed the title
milyin
added a commit
to ZettaScaleLabs/zenoh-flat-jni
that referenced
this pull request
Jul 18, 2026
* Shared string-backed Parameters + native oracle declarations Selector parameters get ONE pure-Kotlin implementation in the shared tier (kotlin/io/zenoh/jni/query/Parameters.kt), mirroring Rust's zenoh-protocol/core/parameters.rs exactly: string-backed state, ';'-split iteration skipping empty chunks, first-'=' key/value split, no percent-decoding, infallible construction, first-match-wins get, insert and remove normalizing the string, last-wins map conversion. Both SDKs (zenoh-java, zenoh-kotlin) reduce their io.zenoh.query.Parameters to thin facades over it — ending the duplicated (and Rust-divergent) per-SDK parsers. No JNI crossing on any production path. Declare the zenoh-flat parameters_get/insert/remove/is_well_formed oracle externs (io.zenoh.jni.query free functions): used only by the SDKs' correspondence tests, per the rule that a pure-JVM reimplementation of native semantics must be validated against the native oracle. Companions: ZettaScaleLabs/zenoh-flat#4 (oracle fns, merges first), zenoh-java / zenoh-kotlin facade PRs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Parameters.remove: follow the documented Rust contract, note the upstream bug Empirical probe of zenoh's parameters::remove shows an iterator-consumption bug: 'find' advances past every entry up to and including the first match before 'filter' builds the result, so entries PRECEDING the match are dropped ('b=2;a=1;c=3' remove 'a' -> 'c=3') and removing an absent key erases the whole string. The shared implementation keeps the documented "preserving the insertion order" semantics instead; the divergence is pinned by a canary in zenoh-java's ParametersCorrespondenceTest. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Parameters: trim trailing separators at construction, as Rust does The correspondence test caught two divergences from the native oracle (get("") on "=", insert after trailing '=' runs): Rust's Parameters::from trim_end_matches ';', '=', '|' before storing the string. Mirror it in fromString. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Declare the full zenoh-flat parameters API; reframe the JVM adaptation parameters_values / parameters_contains_key / parameters_extend join the declarations — the complete parameters-processing API of zenoh-flat, regular any-language API (zenoh-flat-c wraps it directly). The JVM SDKs run the same semantics in pure Kotlin on their production path because crossing JNI per string operation is expensive — a JNI peculiarity, not a zenoh-flat design choice — and verify the correspondence in tests; build.rs comment and the shared Parameters KDoc now say exactly that. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * ci: pin zenoh-flat to merged main (parameters API, #4) The previous pin (bb410ccb) long predates the parameters functions, so the new declarations could not resolve in CI. Local regen against 1ece3df is byte-identical. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Selector-parameters processing as regular zenoh-flat API — the translatable mirror of
zenoh::query::Parameters, per the crate's charter of covering the main zenoh API in a form any language binding can consume. Parameters travel as the plaina=b;c=d|e;f=gstring; every operation takes and returns strings, with exact zenoh semantics (construction ignores trailing;/=/|, entries split on;, key/value on the first=, no percent-decoding, first-match-wins lookup, normalized rebuild on mutation).Dedicated
src/base/query/parameters.rsmodule, full struct mirror:parameters_get(s, k) -> Option<String>Parameters::getparameters_values(s, k) -> Vec<String>Parameters::values(|-split; empty when absent)parameters_contains_key(s, k) -> boolParameters::contains_keyparameters_insert(s, k, v) -> StringParameters::insert(resulting string; read the old value withparameters_getfirst — the tuple return does not translate)parameters_remove(s, k) -> StringParameters::remove(ditto)parameters_extend(s, other) -> StringParameters::extend(other's values win)parameters_is_well_formed(s) -> boolis_well_formedConsumers: zenoh-flat-c wraps these directly as its C parameters API; zenoh-flat-jni declares them, while the JVM SDKs run the same semantics in pure Kotlin on their production path (crossing JNI per string operation is expensive — a JNI adaptation, not a zenoh-flat design choice) and verify the correspondence against these functions in tests (which is how the
removebug fixed in eclipse-zenoh/zenoh#2687 was found).Companions: ZettaScaleLabs/zenoh-flat-jni#9, zenoh-flat-c PR, eclipse-zenoh/zenoh-java#492, eclipse-zenoh/zenoh-kotlin#670.
🤖 Generated with Claude Code