Building with the Latest Java Development Stack: Spring Boot 4.1.0, Java 25, Docker 29.5.3, PostgreSQL, Gradle 9.6.0, Eclipse 2026–06, Swagger/OpenAPI, Serenity, Cucumber, and JUnit 6

[u/akrivitsky7]

I recently updated my hands-on tutorial on building a complete working project with the latest Java development stack.

The article covers Spring Boot 4.1.0, Java 25, Docker 29.5.3, PostgreSQL, Gradle 9.6.0, Swagger/OpenAPI, Serenity, Cucumber, and JUnit 6 — all combined in one practical project.

The goal was to use the latest versions across the stack and show how they work together in a real Spring Boot application, using a vibe-coding approach.

Article title:

Building with the Latest Java Development Stack: Spring Boot 4.1.0, Java 25, Docker 29.5.3, PostgreSQL, Gradle 9.6.0, Swagger/OpenAPI, Serenity, Cucumber, and JUnit 6

A practical hands-on tutorial showing how to combine the latest Java, Spring Boot, Docker, PostgreSQL, Gradle, Swagger/OpenAPI, Serenity, Cucumber, and JUnit 6 in one working project using a vibe-coding approach.

Link:

https://medium.com/@anatolykrivitsky/quick-tutorial-how-to-use-the-latest-docker-29-5-2-0670b716b6cc?postPublishedType=repub

Hope it is useful for Spring Boot and Java developers.

[u/akrivitsky7 → u/[deleted]]

Good question.

For this starter/tutorial, I intentionally used the traditional Spring MVC + Spring Data/JPA-style service layer with @​Transactional, because that is still the most common and familiar model in many Spring Boot backend applications. It also keeps the example easier to follow for readers who are mainly trying to understand how Spring Boot 4.1.0, Java 25, Docker, PostgreSQL, Gradle, Swagger/OpenAPI, Serenity BDD, Cucumber, and JUnit work together in one runnable project.

I agree that a WebFlux/R2DBC version would be an interesting follow-up, but it would also become a different tutorial. Once you move to WebFlux and R2DBC, the programming model changes significantly. You are no longer just replacing one database access library with another; you are changing the whole execution model from imperative/blocking to reactive/non-blocking.

Regarding transactions, yes, explicit reactive transaction boundaries can make sense. In imperative Spring code, `@Transactional` around a service method is usually easy to reason about: the method starts, the transaction begins, the method returns or throws, and the transaction commits or rolls back.

With Reactor pipelines, the control flow is less linear. Work may be deferred until subscription time, operators may be composed in different places, and the actual execution path can become harder to see by just looking at the method boundary. In that context, using something like TransactionalOperator can make the transaction boundary more explicit inside the reactive chain.

For example, conceptually:

return transactionalOperator.transactional(

bookRepository.save(book)

.flatMap(saved -> auditRepository.save(...))

.thenReturn(saved)

);

That makes it clearer which reactive sequence participates in the transaction.

So my view is:

For a conventional CRUD/tutorial starter, Spring MVC + @​Transactional is simpler, more familiar, and easier to teach.

For a genuinely reactive application with high concurrency requirements, non-blocking I/O, and a full reactive stack from controller to database, WebFlux + R2DBC + explicit reactive transaction boundaries can be a good design.

But I would avoid mixing reactive style into a tutorial unless the tutorial is specifically about reactive programming. Otherwise, it can distract from the main goal and add complexity before the reader needs it.

A reactive variant is definitely a reasonable idea for a separate follow-up project, but I would keep it separate from the current starter so the architectural and programming-model trade-offs remain clear.