asmhatre/hibernate-demo
1
0
Fork 0
Code Activity

Add Hibernate 7 batches 2-6, batch 7, and batch 8: mapping styles, JPA annotations, natural IDs, @Immutable, stored procedures, in-memory test databases, JNDI mocking, proxies, associations, temporal mapping, named queries, HQL, Criteria API, EntityManager bootstrapping, Ehcache 3 L2 cache configuration, HikariCP connection pooling, Hibernate Validator CDI integration, aggregate functions, sorting, pagination, interceptors, and Hibernate Search 8 (Hibernate 7.4.5.Final + Spring Boot 4.1.1 + JDK 25)

Browse Source
This commit is contained in:
asmhatre
2026-09-20 06:06:42 +00:00
committed by Claude
commit 8568c0ce6c
330 changed files with 23668 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/00-versions.md
Executable
+83
View File
@@ -0,0 +1,83 @@
# 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)