JPA requires mutable classes.

Records ergonomics is terrible if you want to replace data classes with records, even if immutable is OK. You need to write builders. You can't really write code like

  new Person(id, null, null, null, lastName, firstName, null, null, null, null, null, null, null, age);

Withers can help with that, but they're not even in any kind of experimental shape right now, so we have many years to wait for it.

Right now records are only fine for very simple use-cases like Point(x, y). Or if you want to write or generate builders. But at this time you don't really save anything, if you can generate a builder, you can generate a class as well.

Yeah, I don't like JPA because of lack of support of immutable types (records or my own classes that don't have setters, only constructor).

If you have data class with more than 5 fields then you have it wrong. Builders are like lombok and like field injection: hide poor class design.

If using a class hurts, it is badly designed and should hurt until it is refactored/split up into consumable parts.

I use records extensively, but those are in most cases converted classes which were small and immutable. JPA being one of the exceptions (a stuck in the past spec)

Some of database tables I worked with had over 100 columns.

I don't think you need to map all of them to a single object - projections work well here.

There are very few cases where you need to work simultaneously on that many columns.

I can't imagine other way of dealing with database rather than using a single class per table. Projections are a way to optimize some niche queries which are too slow otherwise.

A 100 column table will be slow either way.

Why not have it like new Person(name, new Address(…))? Nesting is allowed.

Records not being extend(able) is the reason why Lombok is still mostly needed...

Why would you need extend over implements? I found sealed interfaces with records really cool.