GitHub user ravjot28 added a comment to the discussion: MoR support for the standalone Java client (new HoodieJavaReadClient)
The first PR is now open: **[#19872 — Preserve writer schemas when decoding Avro payloads](https://github.com/apache/hudi/pull/19872)**. It covers the shared payload/schema fix and Spark serialization compatibility, with the non-Spark Kryo compatibility boundary called out explicitly. Its 16 focused tests pass locally; upstream CI results are not yet available. The earlier [successful fork CI run](https://github.com/ravjot28/hudi/actions/runs/34168606289) validates the combined implementation, not this newly split PR. Thank you, **Shiyan Xu and Nadine Farah**, for your guidance on the Java-client improvements and the contribution process. The remaining work is prepared locally for separate PRs: - Java SIMPLE bucket-index support and write routing. - `HoodieJavaReadClient` and the remaining MOR write/table-service lifecycle changes, with applicable Spark/Flink storage-contract tests. - Companion website documentation for usage, configuration, resource ownership, and limitations. The Kafka test-readiness fix is also separated as independent test infrastructure work. These PRs are not open yet; I plan to submit the dependent Java changes in order so reviewers see focused diffs. @vinothchandar, thanks for raising the Hudi 1.x `RecordMerger` APIs. The proposed reader uses the shared `HoodieFileGroupReader`, while the first PR changes `BaseAvroPayload`. That distinction needs to be reviewed against your suggestion before I finalize the remaining Java PRs. I'd welcome guidance on the preferred RecordMerger-based approach and whether the payload prerequisite should be narrowed or reworked. A correction to my original discussion and dev-list email: ordinary Java MOR delta writes and regular compaction already existed. This work adds the standalone reader and addresses specific lifecycle gaps. Internal-schema reconciliation is now covered; CDC-enabled writes are covered through the common extractor, but there is no standalone CDC-output API. Archived incremental ranges and LSM reads remain outside this iteration. Merge readers open one file group at a time and can spill, while planning memory still grows with the selected file groups. I also plan to contribute further Java-client improvements, including the streaming work discussed earlier, to close more applicable gaps with other engines. This matters for teams that want Hudi embedded in their applications without the additional infrastructure cost and operational work of running a Spark deployment. GitHub link: https://github.com/apache/hudi/discussions/19798#discussioncomment-18359759 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
