[Java][JSON] No way to reject a repeated JSON property on read

Đang mở
  • Có gì không ổn?
#4,165 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@pavel-ptashyts đang làm issue này rồi.

Từ ngày 11/10/2026.

  • #4166 của @pavel-ptashyts — đang mở

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java, json
Lĩnh vực
backend

Hướng nghiên cứu

Read the existing failOnMissingRequiredProperties builder option and compare how JSON readers are generated and interpreted; the issue names both paths but gives no file locations or tests. Then assess how class annotations, mixins, flattened properties, null handling, and nested classes fit the proposed duplicate detection semantics. Done means a per-class option rejects repeated known properties while preserving the stated behavior for unknown, ignored, and any-setter entries.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

What happens

When a JSON object repeats one of the bean's known properties, fory-json keeps the last value without an error.
There is no builder option and no annotation that rejects such a document.

public static class Request {
  public String id;
  public Long tmax;
  public List<String> bcat = List.of();
}

ForyJson fory = ForyJson.builder().build();
Request r = fory.fromJson(
    "{\"id\":\"r1\",\"tmax\":100,\"bcat\":[\"IAB1\"],\"tmax\":200,\"bcat\":[]}", Request.class);
// tmax=200 bcat=[]

Reproduced on main (b6023929) and on 1.7.6, JDK 25.

Why it matters

RFC 8259 leaves duplicate names to the implementation, and parsers disagree on them: some take the first value,
some the last, some fail. A service that receives a document from a third party and passes it on (or checks it
in one component and acts on it in another) can therefore read a different value than the next hop does. For
input validation it is useful to refuse such a document outright.

Our case: we receive OpenRTB bid requests from external exchanges and answer a request that repeats a top-level
field ("tmax", "imp", ...) with HTTP 400. Nested objects of the same request stay lenient, and so do our
other models. Today we do this on Jackson with a custom module that wraps the root properties of one class. With
Fory there is no hook for it, so this is one of the things that keep us from moving the inbound request read to
Fory.

Jackson only offers StreamReadFeature.STRICT_DUPLICATE_DETECTION, which is parser-wide: it applies to every
object and map in every document and keeps a name set per object, so it costs every read. A per-class switch is
both cheaper and closer to what applications need.

Proposal
  • ForyJsonBuilder.failOnDuplicateProperties(boolean), default false (today's behaviour: the last value
    wins), next to failOnMissingRequiredProperties.
  • A class annotation @JsonDuplicateProperties(fail = true | false) that overrides the builder setting for one
    class. Like @JsonInclude, it is not inherited, and an exact-target @JsonMixin can supply it.

Semantics when enabled for a class:

  • A known property of that class (field, setter, @JsonCreator parameter, a name flattened in by
    @JsonUnwrapped) that appears twice in one object fails the read with a ForyJsonException that names the
    property.
  • An explicit null counts as an occurrence, also when onNullRead is SKIP.
  • Unknown and ignored names, and @JsonAnySetter entries, are not tracked.
  • Nested objects follow their own class setting; enabling it on the root does not make children strict.

Cost: when disabled, the generated readers stay exactly as they are today (the decision is made at code
generation time, like onNullRead). When enabled, each object of that class marks one bit per known property
it reads, so there is no per-read allocation and no name set.

I have an implementation in progress for the generated readers and the interpreter and would like to open a PR
for it if this direction is acceptable. Happy to adjust the API shape (for example an enum instead of the
boolean, or only the class annotation) to whatever fits the project better.

Ngôn ngữ chính
Java
Star
4.6k
Fork
470
Merge trung bình
9 giờ 28 phút
Pull request đã merge (30 ngày)
33

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/fory

Tất cả issue của apache/fory

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.