Replacing org.n52.jackson.datatype.jts.JtsModule for Jackson 3: Introducing io.github.aytronnfr.jackson.jts.JtsModule
If you are migrating to Spring Boot 4 and Jackson 3, you have probably hit this problem:
- your geospatial JSON stack still depends on Jackson 2-era modules,
- but your app now runs on
tools.jackson.*.
I hit the same wall and built a replacement module:
-
old:
org.n52.jackson.datatype.jts.JtsModule -
new:
io.github.aytronnfr.jackson.jts.JtsModule
Repository: https://github.com/aytronnFR/jts-jackson3-module
TL;DR
-
jts-jackson3-moduleprovides GeoJSON serialization/deserialization for JTS on Jackson 3. - It is designed for Spring Boot 4.x projects using
tools.jackson.*. - It includes round-trip and compatibility tests to reduce migration risk.
Why this module exists
Spring Boot 4 moves to Jackson 3. That means many older JSON modules built around Jackson 2 package names no longer fit cleanly.
For JTS geometries, this can block migration or force ugly temporary workarounds.
This module is a drop-in migration path for teams that need:
- clean support for
org.locationtech.jtsgeometries, - GeoJSON read/write behavior,
- modern build/publish workflow (GitHub Packages + Maven Central).
Compatibility targets
jts-jackson3-module is built for:
- Spring Boot 4.x
- Jackson 3 (
tools.jackson.*) - JTS (
org.locationtech.jts)
Dependency
dependencies {
implementation("io.github.aytronnfr:jts-jackson3-module:0.1.0")
}
Basic usage
import io.github.aytronnfr.jackson.jts.JtsModule;
import tools.jackson.databind.json.JsonMapper;
import org.locationtech.jts.geom.GeometryFactory;
import org.locationtech.jts.geom.PrecisionModel;
@Configuration
public class JsonConfig {
@Bean
public GeometryFactory geometryFactory() {
return new GeometryFactory(new PrecisionModel(), 4326);
}
public static void configJsonMapper(GeometryFactory geometryFactory, Builder builder) {
// 1) Modules
builder.addModule(new JtsModule(geometryFactory));
...
}
}
That’s enough to start serializing/deserializing JTS geometries in a Jackson 3 stack.
Advanced usage: include bbox for selected geometry types
import io.github.aytronnfr.jackson.jts.GeometryType;
import io.github.aytronnfr.jackson.jts.IncludeBoundingBox;
import io.github.aytronnfr.jackson.jts.JtsModule;
var module = new JtsModule(IncludeBoundingBox.forTypes(GeometryType.POINT), 8);
This lets you control output precision and bounding-box behavior for targeted geometry classes.
Migration notes from org.n52... module
When migrating, I recommend this order:
- Replace dependency with
io.github.aytronnfr:jts-jackson3-module. - Register
new JtsModule()in your Jackson 3JsonMapperconfig. - Run contract tests against existing API payload fixtures.
- Validate edge cases: precision, bbox output, null geometry handling.
- Roll out with canary if geospatial payloads are customer-facing.
Testing strategy used in the project
The repo includes:
- round-trip tests for Jackson 3 behavior,
-
compat tests against legacy
org.n52.jackson:jackson-datatype-jts:2.0.0, - shared fixtures for deterministic comparisons.
That is important because geospatial JSON regressions are often subtle (ordering, precision, bbox shape) and can break downstream consumers silently.
CI/CD and publishing
The project includes GitHub Actions for:
- CI on push/PR,
- publish on version tags,
- manual release flow.
Publishing is wired for:
- GitHub Packages
- Maven Central
Practical impact for Boot 4 teams
In real migrations, this removes a key blocker: staying with old module assumptions while the rest of your app has already moved to Jackson 3.
You keep your geospatial payload capability without freezing your platform upgrade.
What’s next
The roadmap I’m focusing on:
- expand compatibility fixtures,
- benchmark serialization overhead on larger geometry sets,
- document migration recipes for common Spring Boot setups.
If you’re migrating a GIS-heavy API to Boot 4, feedback and issue reports are very welcome.
Top comments (0)