hibernate-demo/docs/00-versions.md

00 — Versions

Next: 01 — get() vs load() →

This repository is pinned to:

Component	Version	GA date	Source
Spring Boot	4.1.1	2026-07	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() →