[e3bc54b2]

> Records have existed for years

As a fan of Records, this is a punch to the gut.

The ecosystem is years and years away from using records. Almost every huge monolith decade+ project is still on Java 8, those who moved to something new still can't be liberal with them, because oh look, none of the serialize/deserialize libs can work with them because everything, to this day, abuses reflection for generating objects like a giant fucking hack it is.

Apology for the rant, but I migrated a big project to 21 early this year, am in the middle of migrating another 1M+ line codebase to 21, and the sorry state of records is such a sad thing to witness.

I give a decade before records are anything but 'a fancy feature'.

[xxs]

It's a fair point of stuck w/ java8, yet the reference was about "modern java".

With that said - lombok is not needed at any form there either, use a c-tor with fields and make the public final. If you have too many fields in a class, it's likely a good idea to split it regardless.

In all cases dumb getter/setters are just public fields but taking more meta space (and larger byte code, the latter has some consideration when it comes to inlining)

Also, if I had 1M LOC and my serialization/communication libraries didn't support whatever I've picked - I'd patch the libraries to support it.

[e3bc54b2]

> It's a fair point of stuck w/ java8, yet the reference was about "modern java".

And I'm saying that even after writing the most of the first project (closing in on 100kLOC now) in 21, I still can't have records where the make the most sense (service boundaries) because libs and larger ecosystem don't support them.

> Also, if I had 1M LOC and my serialization/communication libraries didn't support whatever I've picked - I'd patch the libraries to support it.

1MLOC in java land is.. not unusual. And if you're talking about patching libs like jackson/jaxb/whatever, my good person, you truly underestimate how much actual work people have (where Java upgrade is a distant afterthought, I only did it because I wanted to scratch the itch and see how far I could push processes in my org), or how much impact that might have for a drive-by contribution. Updating such core ecosystem libs in java is no small feat. They are used absolutely everywhere, and even tiny changes require big testing. There is a reason you find apache libs in every single project, because they have matured over past couple of decades without such drastic rug-pull of a change.

[xxs]

I did say all that (incl the 1M+) stuff coming from personal experience. I have "fixed" all kind of libraries (incl. database drivers, JDK itself, PKI cert loading, netty/jetty, ORM providers). I'd consider jaxb/jackson on the easy side of things.

Also I'd actively remove all apache commons as well. Even in Java8 most of the functionality is redundant.

With all that I meant it should not be really underestimation.

[e3bc54b2]

You are really part of the cream, and I mean it as an honest compliment.

I am part of the dark matter, although self-initiated java upgrades already put me on the right side of bell-curve.

> Also I'd actively remove all apache commons as well. Even in Java8 most of the functionality is redundant.

I used to think that. Then I had to decompress zip files in memory and selectively process the children. Of course Java has the functionality covered in stdlib, but they require so much boilerplate, and commons-compress was such a pleasure that I was done in 10 minutes. The same goes for other apache libs too.

OTOH, I wholeheartedly agree about Lombok being unjustified curse.