What would you like to be added:
Migrate the 5.x branch off Jackson 2 onto Jackson 3, and bring the JSON Schema tooling up to date:
com.fasterxml.jackson 2.22.1 → tools.jackson 3.2.1 (new coordinates and packages)com.networknt:json-schema-validator 1.5.9 → 3.0.6jsonschema2pojo-maven-plugin 1.3.1 → 1.3.3, with annotationStyle=jackson3
I have this working on a fork — 72 files, +645/−703, full build and test suite green:
Happy to open the PR if there's appetite for it.
Most of it is mechanical, but three parts are worth flagging:
ObjectMapper can no longer be subclassed in Jackson 3. BaseObjectMapper, JsonObjectMapper and YamlObjectMapper stop being ObjectMapper subclasses and become factories built on MapperBuilder. This is the one source-incompatible change for API consumers.- Serializers/deserializers follow the Jackson 3 renames:
writeXField → writeXProperty, SerializerProvider → SerializationContext, tree access via JsonParser.readValueAsTree / DeserializationContext.readTreeAsValue, JsonNode.asText → asString, and checked IOException handling dropped in favour of the unchecked JacksonException.
- json-schema-validator 3 replaces
JsonSchemaFactory/ValidationMessage with SchemaRegistry/Error, and no longer prefixes messages with the instance location.
Two points I'd want a maintainer's call on before this is merge-ready:
schema/workflow.json declares events, functions, errors, retries and auth as "type": "object", while the spec also allows arrays there (and a plain string for start). Validator 1.x tolerated the mismatch; 3.x reports array found, object expected. My branch filters those by keyword + instance location in WorkflowValidatorImpl, which preserves current behaviour but is a workaround. The honest fix is to give those properties their real oneOf shape in the schema — they all carry existingJavaType, so POJO generation shouldn't care. I didn't want to change the codegen schema unilaterally.- A
maven-antrun-plugin step patches jsonschema2pojo output. With useJakartaValidation=true, jsonschema2pojo 1.3.3 emits List<@Valid java.lang.String>, which javac rejects on Java 22+: a type-use annotation on a fully qualified type has to sit as List<java.lang.@Valid String>. See jsonschema2pojo#1586 — the fix is merged (jsonschema2pojo#1778) but unreleased, so the antrun step is a stopgap to delete once a release including it lands.
Why is this needed:
- Jackson 2 is in maintenance mode; 3.x is the line getting features and fixes. The move is breaking, so it belongs at a major boundary rather than being deferred indefinitely.
- Applications already on Jackson 3 that consume this SDK must keep both Jackson generations on the classpath. The coordinates differ (
com.fasterxml.jackson vs tools.jackson), so Maven can't mediate it as a version conflict — it's genuinely two copies of the same library.
json-schema-validator 1.5.9 is well behind (5.x is on 1.5.9, main on 2.0.0).- The generated-code problem above is a hard build blocker on JDK 22+, independent of Jackson.
I'm aware 5.x is in maintenance and this may not be where you want to spend review time.
What would you like to be added:
Migrate the
5.xbranch off Jackson 2 onto Jackson 3, and bring the JSON Schema tooling up to date:com.fasterxml.jackson2.22.1 →tools.jackson3.2.1 (new coordinates and packages)com.networknt:json-schema-validator1.5.9 → 3.0.6jsonschema2pojo-maven-plugin1.3.1 → 1.3.3, withannotationStyle=jackson3I have this working on a fork — 72 files, +645/−703, full build and test suite green:
Happy to open the PR if there's appetite for it.
Most of it is mechanical, but three parts are worth flagging:
ObjectMappercan no longer be subclassed in Jackson 3.BaseObjectMapper,JsonObjectMapperandYamlObjectMapperstop beingObjectMappersubclasses and become factories built onMapperBuilder. This is the one source-incompatible change for API consumers.writeXField→writeXProperty,SerializerProvider→SerializationContext, tree access viaJsonParser.readValueAsTree/DeserializationContext.readTreeAsValue,JsonNode.asText→asString, and checkedIOExceptionhandling dropped in favour of the uncheckedJacksonException.JsonSchemaFactory/ValidationMessagewithSchemaRegistry/Error, and no longer prefixes messages with the instance location.Two points I'd want a maintainer's call on before this is merge-ready:
schema/workflow.jsondeclaresevents,functions,errors,retriesandauthas"type": "object", while the spec also allows arrays there (and a plain string forstart). Validator 1.x tolerated the mismatch; 3.x reportsarray found, object expected. My branch filters those by keyword + instance location inWorkflowValidatorImpl, which preserves current behaviour but is a workaround. The honest fix is to give those properties their realoneOfshape in the schema — they all carryexistingJavaType, so POJO generation shouldn't care. I didn't want to change the codegen schema unilaterally.maven-antrun-pluginstep patches jsonschema2pojo output. WithuseJakartaValidation=true, jsonschema2pojo 1.3.3 emitsList<@Valid java.lang.String>, which javac rejects on Java 22+: a type-use annotation on a fully qualified type has to sit asList<java.lang.@Valid String>. See jsonschema2pojo#1586 — the fix is merged (jsonschema2pojo#1778) but unreleased, so the antrun step is a stopgap to delete once a release including it lands.Why is this needed:
com.fasterxml.jacksonvstools.jackson), so Maven can't mediate it as a version conflict — it's genuinely two copies of the same library.json-schema-validator1.5.9 is well behind (5.xis on 1.5.9,mainon 2.0.0).I'm aware
5.xis in maintenance and this may not be where you want to spend review time.