Upgrading to JDK 17

Jump to bottom Edit New page

Mark Paluch edited this page Oct 19, 2021 · 7 revisions

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.