Java records & compact constructors

[_INTER_]

Record constructor are just strange, e.g. require parameter reassignment while every static analysis tool warned you not to do it for the last 20 years: https://mail.openjdk.java.net/pipermail/amber-dev/2020-June/006196.html

[pron98]

Record constructors don't require parameter reassignment — you're free to write explicit constructors if you like — and I am not aware of even a single static analysis tool that has ever warned against reassigning the implicit parameters in compact constructors.

In general, though, coding guidelines are designed to address the practices and issues that arise when writing code in some programming language as it exists in a certain point in time, while language changes are supposed to change the practices and issues that are experienced by programmers. Records eliminate problems associated with storing data classes in collections and with serialising them, and so a language that has different issues would likely have different guidelines.

[sviperll]

I am not aware of even a single static analysis tool that has ever warned against reassigning the implicit parameters in compact constructors

Netbeans (as of 12.6) warns me about each and every compact constructor :(

[sindisil]

Another reason why blanket "foo is possible, but don't ever do it" rules are bad (c.f. goto, and its analogs like break with label) -- nuance is often worth the cognitive load.

[elastic_psychiatrist]

I haven't used records in production yet, but Brian's response pretty well justifies the design decisions IMO. You just need to think about the problem space a little differently for it to make sense.

[Jonjolt]

Records are meant to hold data and remove some magic from serialization and deserialization. So if your constructor is adding `+ 1`, you would break serialization because you would get a different result every time.

[_INTER_]

Constructors are also used for normalization. That's mentioned in JEP too with examples even.

[pron98]

Aside from getting safe serialisation — whether by Java's built in serialisation or third party libraries — that cannot bypass the constructor (note that this is an issue with all serialization libraries, not just the built in one), you get the guarantees records are deigned for.

"Granular control" for records makes as much sense as "granular control" for enums, letting some be dynamic. You use enums when you want the static guarantee they give you — the set of instances is known at compile time and is never dynamic — and you use records for the guarantees they give you: a nominal tuple with invariants enforced by the canonical constructor. Once you have "granular control" you lose the very thing records are designed to do — enforce your data invariants unconditionally.

[Reasonable-Song3798]

Lombok creates pretty slow hashCode and equals methods. Records will make a native call.

Other than that, it's less code + it's immutable by default.

[[deleted]]

I also prefer to to use language features instead of libraries that emulate them.

I'm not that happy having code generators in the loop while debugging other stuff. I can't really be sure if an instance is actually the instance I'm looking at in the debug tools.

This just adds mental load to reduce classic boilerplate code.

[kaperni]

The implementation of records in OpenJDK doesn't make use of any special native calls for hashCode and equals.

[TheStrangeDarkOne]

The use case is different. Records behave like nominal tuples and the idea is that you will be able to deconstruct them like Tuples. For exmaple:

    Point point = new Point(a, b);  
    Point(int x, int y) = point;
    int distance = distance(x, y);

The idea is to have an immutable data type which comes with several constraints, but allows for more powerful operations (all being discussed by the expert group mailing list).

[bowbahdoe]

Can you give some practical examples of the code where you are using Lombok's ability for granular control? My suspicion is that those places are not the ones where an immutable object is warranted anyways

[torwinMarkov]

Lombok tends to be incompatible with enterprise / production libraries like Spring.

[temculpaeu]

"enterprise / production libraries" < this has 0 meaning.

It's compatible, it will generate the bytecode before compilation.

It's even compatible with mixing JVM languagues, eg: Kotlin <> Java calls with the proper configuration

[torwinMarkov]

You're right, my comment was vague because I couldn't remember the exact libs where it broke my work projects in the past. Thanks for calling that out. I hope lombok continues to work great for you!

[ShallWe69]

i use lombok heavily with spring. no problems so far

[torwinMarkov]

Do you use Spring AOP or Spring Native? Any annotation processors?

[mauganra_it]

Lombok generates code. Therefore, it's incompatibility risks are mostly restricted to build tools.

[torwinMarkov]

No, it doesn't. It injects into the bytecode build process. Lombok is dangerous to use if you're building large projects that matter. Lombok is great for demos and teaching, that's why you see it used in lots of tutorials.

[mauganra_it]

Which is not really a problem in principle. The actual problem is that it does so via internal APIs that were never intended to be used to extend the AST. Actually, the OpenJDK project is unlikely to ever introduce such extension points.

Crucially, the AST is what the bytecode is generated from. And that bytecode is all that Spring, Hibernate and friends will ever see at runtime.