Using 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.
Java's records, Lombok's data, and Kotlin's data classes
61–70 of 294 posts
Re: Java's records, Lombok's data, and Kotlin's data classes
#62They 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.
Isn’t the point that Record classes will be able to be upgraded to value types easily once Valhalla is done? Or am I missing something
Re: Java's records, Lombok's data, and Kotlin's data classes
#63Earlier quoted context omitted.
Can you have an array of 1 million structs, not pointers to structs?
The first question is "through static analysis, can you guarantee that the structs do not leave the scope?" The second question to look at is "which JVM are you using?" Different JVMs may implement this differently. This isn't something that one can say about Java . It is something that one might be able to say about HotSpot, Zulu, or GraalVM.
Re: Java's records, Lombok's data, and Kotlin's data classes
#64Earlier quoted context omitted.
Can you have an array of 1 million structs, not pointers to structs?
1 million is not a lot. I'd begin by asking myselves "can I afford to chase those pointers?", because maybe you can.
Re: Java's records, Lombok's data, and Kotlin's data classes
#65> 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
#66Earlier quoted context omitted.
Scala is usually omitted for one reason or another when Kotlin is compared against Java as a better alternative, which is a shame.
Scala has to the solution to every problem except the problem of too many features.
Re: Java's records, Lombok's data, and Kotlin's data classes
#67Re: Java's records, Lombok's data, and Kotlin's data classes
#68Re: Java's records, Lombok's data, and Kotlin's data classes
#69Earlier quoted context omitted.
Instead of changing few bytes, now I have to copy hundreds of bytes around and add more stuff for GC to collect. Well, they have to obey Wirth's law, I guess.
You have to copy less than you think. Because the data is immutable, you can share everything but the changed fields.
Btw Kotlin allow to make immutable Java records too so clear winner.
Re: Java's records, Lombok's data, and Kotlin's data classes
#70Trying to read in Safari iOS but most of the article text seems to be missing.