GitHub-Spring
/
spring-data-commons
mirror of https://github.com/spring-projects/spring-data-commons.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Updated Upgrading to JDK 17 (markdown)

master
Mark Paluch 4 years ago
parent
740c75270c
commit
febc59da41
1 changed files with 1 additions and 0 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Unified View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 1
      Upgrading-to-JDK-17.md

1
Upgrading-to-JDK-17.md
Unescape

@ -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. * 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. * 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 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. * 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. * 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. * `var`: Neat, requires some getting-used-to time.

Write Preview
Loading…
Cancel
Save