They 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.
Java's records, Lombok's data, and Kotlin's data classes
11–20 of 294 posts
Re: Java's records, Lombok's data, and Kotlin's data classes
#12Trying 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
#13Re: Java's records, Lombok's data, and Kotlin's data classes
#14https://kotlinlang.org/docs/jvm-records.html#declare-records...
Re: Java's records, Lombok's data, and Kotlin's data classes
#15Note however that an upcoming version of Java will get first class ergonomic support for manipulating immutable data: https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...
There is also https://github.com/hrldcpr/pcollections
Re: Java's records, Lombok's data, and Kotlin's data classes
#16Re: Java's records, Lombok's data, and Kotlin's data classes
#171. 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.
Re: Java's records, Lombok's data, and Kotlin's data classes
#18Who 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.
Lombok JustWorks™. You forget it's there until you setup a new dev environment and forget to setup the annotation processor in IntelliJ.