Java's records, Lombok's data, and Kotlin's data classes
1–10 of 294 posts
Re: Java's records, Lombok's data, and Kotlin's data classes
#2I'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.
Re: Java's records, Lombok's data, and Kotlin's data classes
#3Trying to read in Safari iOS but most of the article text seems to be missing.
Re: Java's records, Lombok's data, and Kotlin's data classes
#4One 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.
Re: Java's records, Lombok's data, and Kotlin's data classes
#5They 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.
Re: Java's records, Lombok's data, and Kotlin's data classes
#6> Actually, records are even better* than tuples. EP 395 says:
> > Records can be thought of as nominal tuples.
They are certainly not better, that's just a sad click-bait (the author even admits that).
Sometimes nominal typing is better and sometimes structural typing is better. Forcing people to always use nominal types just ends in a lot of generic or long/meaningless names - one can already see this in Java.
Re: Java's records, Lombok's data, and Kotlin's data classes
#7Trying to read in Safari iOS but most of the article text seems to be missing.
Same.
Re: Java's records, Lombok's data, and Kotlin's data classes
#8Records are good but if you want this in Lombok don't you just use @Getter instead of @Data to generate read only methods?
Serialization is handled by Java bean getters and setters just fine. I don't really see an advantage.
Re: Java's records, Lombok's data, and Kotlin's data classes
#9Who is arguing otherwise? It's assumed that when a language adds a new feature that's historically been provided by libraries, it's probably better optimized. CompletableFutures, Streams, Date/Time. For many they've replaced libraries filling the gaps.
But not all of us can use JDK 14, and will continue to use Lombok if we're writing in Java.
Re: Java's records, Lombok's data, and Kotlin's data classes
#10Trying to read in Safari iOS but most of the article text seems to be missing.
Only half the code is rendering for me as well, Firefox iOS