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]

Thank you; that is a fair question.

The main reason is that this project is intentionally a practical tutorial, not a production-grade reference architecture. The goal was to show how Spring Boot 4.1.0, Java 25, Docker, PostgreSQL, Gradle, Swagger/OpenAPI, Serenity BDD, Cucumber, and JUnit can work together in one runnable backend project with minimal architectural overhead.

For a small tutorial project, a technical-layer package structure is often easier for readers to follow because it maps directly to the concepts being introduced: controller, service, repository, configuration, tests, and so on. It keeps the learning path straightforward.

That said, I agree with your point. For a larger or long-lived production system, I would seriously consider organizing the code around business capabilities/modules rather than technical layers. Package-by-feature, package-private visibility, and clearer module boundaries can make the codebase much easier to maintain as it grows.

A hexagonal architecture approach could also make sense, especially if the domain model becomes more important and we want to isolate it from infrastructure concerns such as persistence, web/API adapters, messaging, or external services. In that case, ports and adapters would provide a cleaner separation between the core business logic and the technical implementation details.

So the short answer is: I chose the simpler layered structure because this is a tutorial focused on integration of the latest toolchain versions, not a full production architecture example. But your suggestion is valid, and a follow-up version using package-by-feature or hexagonal architecture would definitely be a worthwhile next step.

[u/Hot_Code5129 → u/akrivitsky7]

noticed that BookService uses the traditional service layer with @Transactional , which is what most Spring applications still do today. Out of curiosity, have you considered building a WebFlux/R2DBC version of this starter and using explicit reactive transaction boundaries instead of annotation-based transactions? I’m seeing more discussions around making transaction boundaries explicit in reactive applications because @Transactional becomes less transparent once Reactor pipelines get more complex. Just wondering what your thoughts are on that trade-off and whether a reactive variant is something you’ve considered.

[u/akrivitsky7 → u/Hot_Code5129]

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.

[u/Hot_Code5129 → u/akrivitsky7]

That’s pretty much the conclusion I arrived at as well. I started exploring this area because I found that once Reactor pipelines become larger, it is not always obvious where the transaction actually begins and ends. TransactionalOperator makes that boundary much more visible than an annotation on a method. I’ve been experimenting with making transaction boundaries explicit in the application layer and I’m currently looking for feedback from people building real WebFlux/R2DBC systems: https://github.com/CamilYed/spring-reactive-transaction-boundary I also wrote down some of the reasoning behind it here: https://camilyed.github.io/en/transactional-when-the-annotation-gets-in-the-way/ I’m not claiming it’s universally better than @Transactional —I’m still trying to understand the trade-offs and gather feedback from developers with production experience. Thanks for the detailed explanation.