Upgrading to JDK 17 - spring-projects/spring-data-commons GitHub Wiki

This page describes the experience of the Spring Data team while upgrading the project build from a JDK 8 to JDK 17 baseline.

Related issues

Easy to miss

  • Jakarta EE 9 Migration: javax.enterprise.inject.spi.Extension service loader metadata must be renamed to jakarta.enterprise.inject.spi.Extension.

Learnings

  • Several dependencies (EJB API, Transaction API, Interceptor API) could be safely removed without breaking anything.
  • Newer javadoc requires presence of compiled code (https://github.com/spring-projects/spring-data-build/issues/1546) otherwise it fails with not found errors.
  • Javadoc in modulepath breaks when dependencies ship split packages (https://github.com/spring-projects/spring-data-build/commit/4c30d24a446930e44d67cff6aa4304672f92db7e)
  • Javadoc style: Watch out for missing references or self-closing tags, especially during cherry-picking or rebase.
  • Records: Seem to work well when using internal components. Records do not seem a good choice when exposing public API. Property accessors and related items (equals/hashCode/toString) follow semantics that can be undesirable with our general design.
  • Sealed classes: Similar to records, can be a good choice for internal components. Sealed classes however do not work well with Mocking as the subtypes are restricted and API users cannot create a mock instance.
  • var: Neat, requires some getting-used-to time.
  • instanceof with Pattern variable (foo instanceof String theString): A proper replacement for instanceof + cast.
  • Textblocks: A nice fit for @Query with a big query. Makes multi-line strings much more readable.