84 lines
5.4 KiB
Markdown
Executable File
84 lines
5.4 KiB
Markdown
Executable File
# 00 — Versions
|
||
|
||
[Next: 01 — get() vs load() →](01-get-vs-load.md)
|
||
|
||
This repository is pinned to:
|
||
|
||
| Component | Version | GA date | Source |
|
||
|---|---|---|---|
|
||
| Spring Boot | `4.1.1` | 2026-07 | [spring.io/blog](https://spring.io/blog/) |
|
||
| Hibernate ORM | `7.4.5.Final` | — | resolved by Spring Boot 4.1.1's dependency management |
|
||
| Spring Framework | `7.0.9` | — | pulled in transitively by Boot 4.1.1 |
|
||
| Jakarta Persistence | `3.2.0` | — | `jakarta.persistence-api` |
|
||
| Java | `25` (Temurin 25.0.4.1 LTS) | 2025-09 | latest LTS at the time this repo was built |
|
||
| H2 | `2.4.240` | — | in-memory, `DB_CLOSE_DELAY=-1` |
|
||
| HSQLDB | `2.7.3` | — | in-memory |
|
||
| Apache Derby | `10.16.1.1` | — | in-memory; dialect lives in `hibernate-community-dialects`, not `hibernate-core` |
|
||
| simple-jndi | `0.25.0` | — | `com.github.h-thurow:simple-jndi`, test scope (the `simple-jndi:simple-jndi` groupId is an abandoned fork — don't use it) |
|
||
| JUnit Jupiter | `6.0.3` | — | via `spring-boot-starter-test` |
|
||
|
||
## The pin was deliberately bumped mid-batch: `4.1.0`/`7.4.1.Final` → `4.1.1`/`7.4.5.Final`
|
||
|
||
Earlier chapters in this repository (00–03) were originally written and verified against Spring
|
||
Boot `4.1.0`, which resolves Hibernate ORM `7.4.1.Final`. This repository has since been bumped
|
||
to Spring Boot `4.1.1`, which resolves a *different* Hibernate patch, `7.4.5.Final` — four
|
||
Hibernate patch releases ahead, from the same "4.1" Spring Boot minor line. Every chapter added
|
||
this session (04–14), and this file, are verified against the new pin: `7.4.5.Final`. If you spot
|
||
`7.4.1.Final` or Spring Boot `4.1.0` anywhere in this repository outside of this historical note,
|
||
that is stale and should be corrected.
|
||
|
||
This is worth explaining precisely, because the mechanism is the same one that could bite you on
|
||
your *next* bump, not just the one already made.
|
||
|
||
Checking `spring-boot-dependencies-4.1.0.pom` directly showed
|
||
`<hibernate.version>7.4.1.Final</hibernate.version>` — so on Boot 4.1.0, this repo's `pom.xml`
|
||
did not need to override anything to get 7.4.1.Final; the `<hibernate.version>` property was
|
||
redundant with what Boot already resolved, kept only so the pin was visible without cracking open
|
||
Boot's own POM.
|
||
|
||
That stopped being true one patch release later. `spring-boot-dependencies-4.1.1.pom` resolves
|
||
`hibernate.version` to `7.4.5.Final` — a different Hibernate patch from the same Spring Boot
|
||
minor version, four Hibernate patch releases apart. Bumping this repo's parent to `4.1.1`
|
||
*without* also updating the `<hibernate.version>` property in `pom.xml` would have silently kept
|
||
`7.4.1.Final` (the explicit property would have overridden Boot's own management) instead of the
|
||
`7.4.5.Final` Boot actually intends for that release — which is exactly the trap this repo avoids
|
||
by keeping the property in lockstep with whatever Boot version is pinned, rather than treating it
|
||
as a one-time, set-and-forget value.
|
||
|
||
| Spring Boot version | Hibernate version Boot resolves |
|
||
|---|---|
|
||
| `4.0.8` | `7.2.24.Final` |
|
||
| `4.1.0` | `7.4.1.Final` |
|
||
| `4.1.1` | `7.4.5.Final` |
|
||
|
||
The lesson generalizes past this one bump: **never assume a Spring Boot patch release leaves
|
||
Hibernate's patch version untouched.** Two Boot releases that look adjacent by patch number
|
||
("4.1.0" vs "4.1.1") can be four Hibernate patch releases apart. Always re-check
|
||
`spring-boot-dependencies-<version>.pom` directly (or run a `mvn dependency:tree` /
|
||
`dependency:resolve` against the new parent) after any Boot version bump, rather than assuming
|
||
last time's Hibernate pin still applies.
|
||
|
||
## Databases and other dependencies added since the original three-chapter batch
|
||
|
||
Chapters 04–14 exercise three JDBC databases side by side, plus a handful of dependencies none
|
||
of chapters 00–03 needed:
|
||
|
||
| Component | Version | Why it's here |
|
||
|---|---|---|
|
||
| H2 | `2.4.240` | primary in-memory database for most chapters |
|
||
| HSQLDB | `2.7.3` | genuine SQL/PSM stored procedures (chapter 08); cross-database comparison (chapter 09) |
|
||
| Apache Derby (`derby` + `derbytools`) | `10.16.1.1` | cross-database comparison (chapter 09) |
|
||
| `hibernate-community-dialects` | `7.4.5.Final` | **required**, not optional — `DerbyDialect` was removed from `hibernate-core` in Hibernate 6.2+ and now lives here, under `org.hibernate.community.dialect` |
|
||
| `com.github.h-thurow:simple-jndi` | `0.25.0` | mocking a JNDI `DataSource` without a real container (chapter 10) — test scope only |
|
||
| `tools.jackson.core:jackson-databind` | managed by Boot's BOM | required for `@JdbcTypeCode(SqlTypes.JSON)` to work at all (chapter 05) — `spring-boot-starter-data-jpa` alone does not pull in a JSON mapper |
|
||
| `hibernate-jcache` + `javax.cache:cache-api` + `org.ehcache:ehcache` (`jakarta` classifier) | `7.4.5.Final` / `1.1.1` / `3.10.8` | measuring `@NaturalIdCache` L2 behavior with real numbers (chapter 06) — see chapter 09 for the classpath-pollution side effect this has on *every other test in the repo*, which is why `hibernate.cache.use_second_level_cache: false` is pinned explicitly in `application.yml` |
|
||
|
||
## Verified against `maven-metadata.xml`, not Maven Central's search index
|
||
|
||
Verified against `maven-metadata.xml` on `repo1.maven.org`, not against Maven Central's
|
||
`solrsearch` API — that index has been observed stale from this kind of sandboxed build
|
||
environment (it reported an old Spring Boot release as newest well after a later one had
|
||
shipped), so it should not be trusted for currency checks.
|
||
|
||
[Next: 01 — get() vs load() →](01-get-vs-load.md)
|