[5.x] Migrate to Jackson 3 and json-schema-validator 3 #1577

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.6
• jsonschema2pojo-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:

• Branch: https://github.com/kuflow/open-workflow-specification--sdk-java/tree/5.x
• Single commit: kuflow@02bb6ba

Happy to open the PR if there's appetite for it.

Most of it is mechanical, but three parts are worth flagging:

1. 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.
2. 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.
3. 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.