dev.westyx.nexus.json.JsonValue, the SDK’s own immutable JSON tree.
Why not Jackson’s JsonNode
Because it would decide your Spring Boot version for you.
Jackson 2 lives in com.fasterxml.jackson and Jackson 3 lives in tools.jackson. They are different namespaces, deliberately, so the two can co-exist on a classpath during a migration. Spring Boot 3 ships the first and Spring Boot 4 ships the second.
A JsonNode on getConfig would therefore have pinned this SDK to one Jackson major, and through it to one Spring Boot major: the starter would have had to ship as two artifacts, and upgrading Spring Boot would have meant swapping SDK coordinates. Returning a type the SDK owns removes the coupling - one artifact serves Spring Boot 3.5, 4.0 and 4.1.
Which Jackson does the SDK use
Whichever one your application already has. Both are<optional> dependencies, so the starter adds neither to your classpath.
Selection happens once, when the client is built, and the SDK reports it on startup:
With no Jackson on the classpath at all, client construction fails with a
NexusException that names both sets of coordinates - not a NoClassDefFoundError from somewhere inside the SDK.Reading values
JsonValue carries exactly what JSON has: strings, numbers, booleans, null, objects and arrays. Numbers are held as BigDecimal, so nothing is lost between the wire and whichever accessor you call.
Absent lookups return
missing() rather than null, so value.get("a").get("b").asString("") is safe without intermediate checks.
Binding to your own types
getConfigAs goes through the application’s object mapper, so your modules, naming strategy and date handling all apply:
ObjectMapper bean - on either Jackson major, through two nested @ConditionalOnClass configurations. Nothing to configure.
Outside Spring, wrap a mapper yourself:
myMapper.readValue(value.toJson(), MyType.class).
Migrating from v0.10.0
getSecret, getFlag, evaluateAB and every other method are unchanged.
