I'm not sure what it's taking about for the "with" feature: https://nipafx.dev/java-record-semantics/#with-blocks
In Kotlin data classes, it's already implemented (just called copy) https://kotlinlang.org/docs/data-classes.html#copying
Java's records, Lombok's data, and Kotlin's data classes
31–40 of 294 posts
Re: Java's records, Lombok's data, and Kotlin's data classes
#32One of the best things about Records is that they guide you to creating immutable data structures, which Lombok does not. This, along with the reduction of boilerplate, greatly reduces the cognitive load required to understand a lot of code.
Lombok has @Value classes, which I use a lot. Is there something about them that does not guide you to creating immutable data structures?
Re: Java's records, Lombok's data, and Kotlin's data classes
#33I think the article is misleading in the list of advantages over Kotlin's Data Classes. 1. Destructuring - available in Kotlin 2. Copy with change - available in Kotlin 3. Serialization - not sure why Kotlin data class would not be serializable 4. Boilerplate - Kotlin takes care of equals and hashCode Huge disadvantage that matters to me is that record fields cannot be mutated. It makes the records much less useful.
"Huge disadvantage that matters to me is that record fields cannot be mutated. It makes the records much less useful." No. It makes them much more useful.
Well it means that the second you need a setter you can't use records so all the boilerplate remains.
Re: Java's records, Lombok's data, and Kotlin's data classes
#34IF you're not on Java 14 yet (70% of industry?[1])...
this post shows two other alternatives for Lombok:
https://medium.com/@vgonzalo/dont-use-lombok-672418daa819
Autovalue & Immutables
Re: Java's records, Lombok's data, and Kotlin's data classes
#35They are still classes, still live on the heap and still need to be garbage collected. Compare with value types that live on the stack in other languages such as Swift, Go and Julia.
The heap is an implementation detail. With escape analysis, the compiler can allocate the data on the heap, stack, or even stick it in registers. https://www.beyondjava.net/escape-analysis-java https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacemen... https://www.javaadvent.com/2020/12/seeing-escape-analysis-wo...
Can you have an array of 1 million structs, not pointers to structs?
Re: Java's records, Lombok's data, and Kotlin's data classes
#36I'm never understood why code generation for getters and setters is so over-engineered. Heavy technologies for light work is almost always more trouble than it's worth.
Getters are setters are pointless anyway - unless you're creating read-only properties by only providing getters, reflexively adding a getter and a setter for every property is exactly the same as just marking the property public. It's even worse in the case of immutable objects (like lists or maps), because the getter itself returns a reference to the mutable object. Getters and setters mentality came from a horribl…
get()/set() is the same as a public property, until you change the implementation, while maintaining interface compatibility, which is the point.
In C# you'd have a point, they have parametric properties and readonly properties. So you'd favor just declaring public properties.
But this is why context matters. And OO design principles also depend on this context.
Re: Java's records, Lombok's data, and Kotlin's data classes
#37Earlier quoted context omitted.
Getters are setters are pointless anyway - unless you're creating read-only properties by only providing getters, reflexively adding a getter and a setter for every property is exactly the same as just marking the property public. It's even worse in the case of immutable objects (like lists or maps), because the getter itself returns a reference to the mutable object. Getters and setters mentality came from a horribl…
In languages without property support, reflexively writing getters and setters is the only way to make it possible to go back later and add logic to getting and setting without changing the callsites. Is this a workaround for the combined shackles of mismanaged enterprise environments where changing callsites is impossible for some reason, and legacy language environments where you have to use Java for some reason? Y…
The real question is why is the convention getFoo() setFoo(foo) and not foo() and foo(foo).
Re: Java's records, Lombok's data, and Kotlin's data classes
#38Earlier quoted context omitted.
In languages without property support, reflexively writing getters and setters is the only way to make it possible to go back later and add logic to getting and setting without changing the callsites. Is this a workaround for the combined shackles of mismanaged enterprise environments where changing callsites is impossible for some reason, and legacy language environments where you have to use Java for some reason? Y…
The real question is why is the convention getFoo() setFoo(foo) and not foo() and foo(foo).
Not all languages have overloading.
Re: Java's records, Lombok's data, and Kotlin's data classes
#39Re: Java's records, Lombok's data, and Kotlin's data classes
#40Using Dark Reader extension for Chrome, all of the sample code text goes to the same color as the background so I thought I was scrolling over huge chunks of blank space.
It's not blog authors responsibility to test his blog for all possible extension that some readers might be using. If the reader is using some third-party software that modifies the original blog design, it's his responsibility to disable it if it doesn't work seamlessly.
I agree with this in general, though sometimes incompatibility with popular extensions is an indication that the author isn't following standards.