From febc59da416268bf34fc907ceedec36db5afdd24 Mon Sep 17 00:00:00 2001 From: Mark Paluch Date: Tue, 19 Oct 2021 16:01:22 +0200 Subject: [PATCH] Updated Upgrading to JDK 17 (markdown) --- Upgrading-to-JDK-17.md | 1 + 1 file changed, 1 insertion(+) diff --git a/Upgrading-to-JDK-17.md b/Upgrading-to-JDK-17.md index a184c42..09fbd3c 100644 --- a/Upgrading-to-JDK-17.md +++ b/Upgrading-to-JDK-17.md @@ -15,6 +15,7 @@ This page describes the experience of the Spring Data team while upgrading the p * 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.