Arnošt Havelka

Good article, but IMHO it's still not time for this (to replace Lombok with Records). There is still too many code boilerplate. I recommend to check https://dzone.com/articles/records-vs-lombok?edition=722502

Sorry, but how is your comment relevant to this article?

for "... using a different database for production than in development ...") well. it depends on many aspects, but believe me we are not brave. Our goal is to have the development smooth, efficient and reliable. Therefore, we have many tests for PROD technologies as well. However, as most of us have many environments before going to PROD where tests are not applicable it seems not efficient to me.

BTW have you considered Spring Actuator? It provides the same feature out of the box -> see e.g. Database Health Indicator part in https://reflectoring.io/spring-boot-health-check/.

Nice article, but I have 2 comments:

1. I prefer to use line numbers from article instead of GitHub -> it's hard to see what you are referring to ;-)

2. I don't think the test class is the best solution. Let's imagine you have a different DB provider in tests then in runtime. We use H2 for tests and Oracle for runtime. Such test would be useless to us :-). It depends on the specific project & solution, that's for sure.

> you could use any of the variations in any environment if you want, right?
TEST & PROD environments use strictly the application server. But it's not effective for the local development to need to start AS, deploy application, etc. Instead, we can run our application as standalone application in different configuration / profile. I'm not talking about features, but dependencies -> e.g. we use H2 database in MEM profile, but Oracle in the rest.

Is it clearer?

Well, we use profiles to run our application in different setup -> similar to the test case mentioned by you. Except test we also use MEM (a standalone JAR with all resources embedded inside), FAT (a standalone JAR with real resources) and AS (just WAR to be deployed to application server). By resources I mean database, AMQ, LDAP, etc.

It's not always easy to maintain it, but it really simplies our development life ;-).

for Spring Boot) it supports more languages -> also Kotlin & Groovy. See https://start.spring.io/

Evidently we honor different aspects/approaches. I wish you to find users for your validator.

for "you don't have to create multiple DTOs or litter your code with annotations ") well, it's probably just a matter of prefernce. I prefer annotations more -> to have all definitions at single place.

for "when you want to apply more than one rule to the same field. ") Sorry, I don't understand.

for "I don't see how it is "bad" for testing in the sense that ") The static methods are hard to mock.

what's the benefit comparing javax validation? It seems better and more standard way. Spring Boot uses it natively and it's not using static approach -> it's "bad" for testing.

Good catch of my typo. Thanks!

I recommend to avoid using @Autowired annotation and rather use constructor injection without it. I got this recommendation on Spring certification training. It promotes independence and testability.

Note: There are more wiring possibilities. I wrote about them e.g. here https://dzone.com/articles/smart-dependency-injection-with-spring-overview.

I believe so. We are used to use generics anyway. I use this approach a lot. It simplify the usage when I want just a specific bean.

correct! It's fixed now.