Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

nipafx.dev

Post reply on HN
Print view View original

51–60 of 294 posts

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

#51

Post by im3w1l »

anonymoushn wrote: post #35
shagie wrote: post #26

Earlier quoted context omitted.

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?

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

#52

Post by vbezhenar »

valenterry wrote: post #45
throwpupper wrote: post #33

Earlier quoted context omitted.

Well it means that the second you need a setter you can't use records so all the boilerplate remains.

You are supposed to create a new copy with some of the fields changed. Just like you do it with the java.time.* classes and others.

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.

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

#53

Post by JackFr »

vbezhenar wrote: post #52
valenterry wrote: post #45

Earlier quoted context omitted.

You are supposed to create a new copy with some of the fields changed. Just like you do it with the java.time.* classes and others.

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.

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

#54

Post by marcinzm »

vbezhenar wrote: post #52
valenterry wrote: post #45

Earlier quoted context omitted.

You are supposed to create a new copy with some of the fields changed. Just like you do it with the java.time.* classes and others.

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.

I mean, you do realize that you're writing Java code right? If you want ultimate low level optimization and control then you're already about ten miles too far downstream to make that turn. Also, I'm guessing the copy overhead is more than offset by the JVM being able to do better optimizations around these data structures.

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

#56

Post by capitainenemo »

jsd1982 wrote: 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.

I was surprised to encounter this as well in Firefox using Dark Mode. I'm still not 100% sure what's going on, because it's rather odd, but if I inspect the page, and add a: .language-java { opacity: 0.99999 } All content instantly renders. Interestingly: .language-java { opacity: 1 } or .language-java { opacity: 0.99999999 } /* probably same as 1 */

Blanks out the content again. Seems rather odd behaviour to me so definitely interested if anyone figures it out, even if this is kind of derailing the discussion.

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

#57

Post by shagie »

iainmerrick wrote: post #48
shagie wrote: post #41

Earlier quoted context omitted.

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.

You’re technically correct that this stuff is all possible in principle, but the answer in practice right now is “no”.

From the link about GraalVM:

> Something that Graal can do that C2 cannot, and a key advantage of GraalVM, is partial escape analysis. Instead of determining a binary value of whether an object escapes the compilation unit or not, this can determine on which branches an object escapes it, and move allocation of the object to only those branches where it escapes.

And from https://docs.oracle.com/en/java/javase/11/vm/java-hotspot-vi...

> The Java HotSpot Server Compiler implements the flow-insensitive escape analysis algorithm described in:

> ...

> After escape analysis, the server compiler eliminates the scalar replaceable object allocations and the associated locks from generated code. The server compiler also eliminates locks for objects that do not globally escape. It does not replace a heap allocation with a stack allocation for objects that do not globally escape.

----

So, some JVMs implement, others only do a limited subset of the optimizations available with escape analysis.

I would not say that the answer of "is it used in practice" is "no."

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

#58

Post by aero142 »

halfmatthalfcat wrote: post #23
valenterry wrote: post #16

Scala's case classes are missing in the comparison (only mentioned briefly at the very end). They offer everything that records do and more. Good to see that Java finally catches up a bit.

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

#59

Post by kaba0 »

vbezhenar wrote: post #52
valenterry wrote: post #45

Earlier quoted context omitted.

You are supposed to create a new copy with some of the fields changed. Just like you do it with the java.time.* classes and others.

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.

Or you know, the JIT will trivially optimize away the old class if it is reassigned to the same variable, as you would use it inside a loop. How do you think the litany of FP languages work? Like Haskell, Scala, Clojure?

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

#60

Post by The_rationalist »

jgrant27 wrote: 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.

Value classes, primitive types and specialized generics will be on the stack on the next versions. There is also this related work https://github.com/microsoft/openjdk-proposals/blob/main/sta...
Post reply on HN