DEV Community

Titouan Despierres
Titouan Despierres

Posted on • Originally published at github.com

Replacing org.n52 JtsModule for Jackson 3: Introducing io.github.aytronnfr.jackson.jts.JtsModule

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-module provides 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.jts geometries,
  • 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")
}
Enter fullscreen mode Exit fullscreen mode

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));
    ...
  }
}
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

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:

  1. Replace dependency with io.github.aytronnfr:jts-jackson3-module.
  2. Register new JtsModule() in your Jackson 3 JsonMapper config.
  3. Run contract tests against existing API payload fixtures.
  4. Validate edge cases: precision, bbox output, null geometry handling.
  5. 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.

Repo: https://github.com/aytronnFR/jts-jackson3-module

Top comments (0)