Live data from Hacker News

Java's records, Lombok's data, and Kotlin's data classes

nipafx.dev

61–70 of 294 posts

Re: Java's records, Lombok's data, and Kotlin's data classes

#61
post #13

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.

[deleted]

Re: Java's records, Lombok's data, and Kotlin's data classes

#62
post #5

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.

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

No they won't (or maybe they will be able to be speculatively opt-deopt?) Value types above a relatively small size are less efficient than references.

Re: Java's records, Lombok's data, and Kotlin's data classes

#63
post #41

Earlier 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.

It's a global array of structs, let's say.

Re: Java's records, Lombok's data, and Kotlin's data classes

#64
post #51

Earlier 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.

No, because my competitors who are attempting to fill the same orders I am attempting to fill are not chasing pointers.

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.

Nominal !≠ named You can have named tuple members while maintaining structural typing, it's not mutually exclusive.

Re: Java's records, Lombok's data, and Kotlin's data classes

#66
post #58

Earlier 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.

Maybe but scalas case classes are super easy to grasp and require no magic like annotations

Re: Java's records, Lombok's data, and Kotlin's data classes

#68
This might qualify as low-grade threadjacking, so I apologize if this is off topic, but who's actually using Java these days? Most devs I know avoid it like the plague, and only use it to maintain legacy codebases or get CS qualifications. Are there any real advantages to using Java in 2021, besides it's mature community/ecosystem/tooling?

Re: Java's records, Lombok's data, and Kotlin's data classes

#69
post #53

Earlier 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.

Then you've invented mutability without references/identity. Except those are desired properties for data classes, unlike for value classes which have such semantic difference.

Btw Kotlin allow to make immutable Java records too so clear winner.

Post reply on HN