xlang: the snake_case conversion of field names is not specified, and the runtimes do not agree
维护者通常 1 天内回复
@dhruv-dagar 已经在做这个了。
开始于 2026年10月19日。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
调研方向
Start with docs/specification/xlang_serialization_spec.md at the cited lines, then compare the conversion functions and cross-language tests named in the issue. The proposal requires choosing and specifying one exact conversion, applying it consistently to written names, sort order, and fingerprints across runtimes, and adding known-answer cases. Done also requires documenting how existing data with affected field names is handled.
由索引模型根据 Issue 内容生成。
描述
Search before asking
- I had searched in the issues and found no similar issues.
Version
All
Component(s)
Other
Minimal reproduce step
Problem
The xlang specification says that field names are "converted to snake_case" (docs/specification/xlang_serialization_spec.md, lines 882 and 1732), and line 1800 refers to "the snake_case field name". It does not define the conversion. Each runtime has its own conversion, and the results are different for acronyms, an acronym followed by a digit, a leading capital letter, and non-ASCII capital letters. Rust and Python write the declared field name without a conversion.
Java, Kotlin, Scala, JS, Dart, C#, Swift, and C++ agree for lowerCamelCase names that have only single ASCII capital letters: they all write createdAt as created_at. A Go field must be exported, so Go writes created_at for CreatedAt. Rust and Python write the declared name, so they match only for a field declared as created_at.
Field name written to TypeDef/TypeMeta (apache/main at a11d257b4)
Every cell comes from a probe program that ran the runtime code at a11d257b4 and, where possible, encoded and decoded a real TypeDef/TypeMeta.
| Input | Java, Kotlin, Scala, JS | Go | Dart | C#, Swift | C++ | Rust | Python |
|---|---|---|---|---|---|---|---|
createdAt |
created_at |
(1) | created_at |
created_at |
created_at |
createdAt (2) |
createdAt |
fooURL |
foo_u_r_l |
(1) | foo_u_r_l |
foo_url |
foo_url |
fooURL (2) |
fooURL |
URLValue |
_u_r_l_value |
u_r_l_value |
u_r_l_value |
url_value |
url_value |
URLValue (2) |
URLValue |
HTTP2Server |
_h_t_t_p2_server |
h_t_t_p2_server |
h_t_t_p2_server |
htt_p2_server |
http2_server |
HTTP2Server (2) |
HTTP2Server |
CreatedAt |
_created_at |
created_at |
created_at |
created_at |
created_at |
CreatedAt (2) |
CreatedAt |
x2Y |
x2_y |
(1) | x2_y |
x2_y |
x2_y |
x2Y (2) |
x2Y |
fooÖl |
fooÖl |
(1) | (3) | foo_öl |
fooÖl |
(4) | (4) |
already_snake |
already_snake |
(1) | already_snake |
already_snake |
already_snake |
already_snake |
already_snake |
- Go writes only exported fields, so a name that starts with a lowercase letter does not reach a Go TypeDef. The
SnakeCasehelper givescreated_at,foo_u_r_l,x2_y, andfooÖlfor these names. - The Rust runtime writes the raw name (probe of
TypeMeta::newwithFieldInfo::new), but#[derive(ForyStruct)]does not compile for a field name with an ASCII capital letter (error E0063, "missing field"). The derive converts identifiers to snake_case atobject/util.rs:410and:422. fooÖlis not a valid Dart identifier.- Rust and Python stop with "Unsupported character for LOWER_UPPER_DIGIT_SPECIAL encoding". Java writes the name as UTF-8.
Some runtimes use a second conversion for the field sort order and the struct fingerprint, and for some inputs it gives a different result from their written name:
| Input | JS sort and fingerprint | Rust sort and fingerprint | Python sort and fingerprint |
|---|---|---|---|
fooURL |
foo_url |
foo_url |
foo_url |
URLValue |
url_value |
url_value |
url_value |
HTTP2Server |
htt_p2_server |
htt_p2_server |
http2_server |
CreatedAt |
created_at |
created_at |
created_at |
fooÖl |
fooÖl |
fooÖl |
foo_öl |
In C#, Swift, and C++, the second conversion gave the same result as the written name for every input.
Conversion functions
- Java:
StringUtils.lowerCamelToLowerUnderscore(StringUtils.java:259), applied atTypeDefEncoder.java:277. The probe built an xlangTypeDef, wrote each field withTypeDefEncoder.writeFieldsInfo, and found the decoded names inTypeDef.getEncoded(). Kotlin and Scala use this fory-core path and were not probed separately. - JavaScript:
lowerCamelToLowerUnderscore(TypeMeta.ts:979) writes the name (TypeMeta.ts:917).toSnakeCase(TypeMeta.ts:1059) gives the sort key, the fingerprint, and the read match. The probe encodedTypeMeta.fromTypeInfo(...).toBytes()and decoded the names. - Go:
SnakeCase(go/fory/util.go:60), applied atfield_spec.go:427and written attype_def.go:509. Unexported fields are skipped attype_def.go:494. The probe ranbuildTypeDefanddecodeTypeDef. - Dart:
_toSnakeCase(fory_generator.dart:5739, called at:1984). The runtime writes the generated identifier unchanged (type_resolver.dart:1181). The probe ranbuild_runnerand readTypeDef.encoded. - C#: the generator's
ToSnakeCase(ForyModelGenerator.Analysis.cs:2803, called at:1490) and the runtime'sLowerCamelToLowerUnderscore(TypeMeta.cs:81, applied at:333). Both usechar.IsUpper, so they convert non-ASCII capital letters. The probe compiled a[ForyStruct]class with the source generator and round-trippedTypeMeta.EncodeandDecode. A type with bothcreatedAtandCreatedAtfails the build with FORY016 ("duplicate structural field identity 'created_at'"). - Swift:
lowerCamelToLowerUnderscore(TypeMeta.swift:1123, applied at:267). The probe compiledSources/Foryand round-trippedTypeMeta.encodeanddecode. The macro'stoSnakeCase(ForyObjectMacro.swift:3698) gives the sort order; the probe ran a verbatim copy of it, because the macro build needs swift-syntax. - C++:
to_snake_case(cpp/fory/util/string_util.h:287), applied attype_resolver.h:1183. The probe builtfory_serialization, ranFieldInfoBuilder::build(), and round-trippedTypeMeta::to_bytesandfrom_bytes. The sort order usesnormalize_field_name(type_resolver.cc:1540), which calls a second, file-localto_snake_case(type_resolver.cc:1479). - Rust: the derive passes the raw identifier to
FieldInfo::new_with_id(rust/fory-derive/src/object/field_codec.rs:201). The probe ranTypeMeta::newwithFieldInfo::newand decoded the result.to_snake_case(string_util.rs:110) gives the sort order and the fingerprint. - Python: the raw dataclass attribute (
meta/typedef.py:1302), written bytypedef_encoder.write_field_info(typedef_encoder.py:247), which the probe ran with a recording buffer._to_snake_case(struct.py:1183) gives the sort order and the fingerprint. The probe did not runbuild_field_infosor the fullencode_typedef, because pyfory does not import without its native extension.
Proposal
Define one exact conversion in the xlang specification, apply it in every runtime for the written name, the sort order, and the fingerprint, and add known-answer cases (for example, the names in the table above) to the cross-language tests. A change to the conversion changes the wire names of some fields, so the specification must also say how existing data with such names is handled.
Related
We found no existing issue for this problem. The row-format schema-evolution work in #3714 uses the Java field-name conversion for its wire names and documents the portable subset, ordinary lowerCamelCase names, until this issue is resolved.
What did you expect to see?
xlang schema should always produce the same normalized names
What did you see instead?
different languages produce different names for the same schema
Anything Else?
Issue diagnosed with Claude Opus 5.5
Are you willing to submit a PR?
- I'm willing to submit a PR!
- 主要语言
- Java
- 星标
- 4.6k
- 派生
- 470
- 平均合并
- 9 小时 28 分钟
- 30 天内合并 PR
- 33
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
apache/fory 的其他 Issue
-
[Python] Compatible xlang read silently drops fields when the peer writes camelCase/PascalCase names未关闭
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 1 天内回复
-
[Build] Add ASF license headers to config files that allow comments可能重新可做 @Swatantra-66 于 31 天前认领,目前没有进行中的 PR。 未关闭enhancement
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
[Rust] Add an option to use Rust native enum可能已有人在做 @BaldDemian 于 22 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 35/100
apache/fory#4177 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
Untyped read collapses a number literal that does not fit a double可能已有人在做 @mohitjoshi-hey 于 24 天前认领。 未关闭bug
难度 3/5 1-2 天 新手友好度 68/100
apache/fory#4170 · 3 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
Registered factory cannot tell a field from the root of the call可能已有人在做 @mohitjoshi-hey 于 21 天前认领。 未关闭bug
难度 4/5 1-2 天 新手友好度 48/100
维护者通常 1 天内回复
相似的 Issue
-
bug key bindings source editor
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 2/5 1-3 小时 新手友好度 78/100
endoflife-date/endoflife.date#11561 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 73/100
conductor-oss/conductor#1824 ·
维护者通常 5 天内回复
-
Type: Possible bug
难度 2/5 1-3 小时 新手友好度 66/100
AntennaPod/AntennaPod#8887 · 1 条评论 ·
维护者通常 1 天内回复