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

Aperta
  • Qualcosa non va?
#4,165 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@pavel-ptashyts ci sta già lavorando.

Dal 11/10/2026.

  • #4166 di @pavel-ptashyts — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java, json
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
4.6k
Fork
470
Merge medio
9h 28m
PR unite (30g)
33

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/fory

Tutte le issue di apache/fory

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.