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

41–50 of 294 posts

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

#41

Post by shagie »

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?

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

#42

Post by zaphar »

throwpupper wrote: post #33
throwaway4good wrote: post #21

Earlier quoted context omitted.

"Huge disadvantage that matters to me is that record fields cannot be mutated. It makes the records much less useful." No. It makes them much more useful.

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

Why would you need a setter for a data class? They add no value there.

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

#45

Post by valenterry »

throwpupper wrote: post #33
throwaway4good wrote: post #21

Earlier quoted context omitted.

"Huge disadvantage that matters to me is that record fields cannot be mutated. It makes the records much less useful." No. It makes them much more useful.

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.

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

#47

Post by commandlinefan »

whatshisface wrote: post #30
commandlinefan wrote: post #22

Earlier quoted context omitted.

Getters are setters are pointless anyway - unless you're creating read-only properties by only providing getters, reflexively adding a getter and a setter for every property is exactly the same as just marking the property public. It's even worse in the case of immutable objects (like lists or maps), because the getter itself returns a reference to the mutable object. Getters and setters mentality came from a horribl…

In languages without property support, reflexively writing getters and setters is the only way to make it possible to go back later and add logic to getting and setting without changing the callsites. Is this a workaround for the combined shackles of mismanaged enterprise environments where changing callsites is impossible for some reason, and legacy language environments where you have to use Java for some reason? Y…

> go back later and add logic to getting and setting

Which, realistically, you're virtually never going to do - at least not often enough to justify the boilerplate and especially in the case of things like "records" which were probably auto-generated from a schema (with obligatory getters and setters) anyway. If you did, you'd end up confusing all of your callers who probably wrote client code presuming that what they provided in the setter was going to be exactly what they get back in the getter.

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

#48

Post by iainmerrick »

shagie wrote: post #41
anonymoushn wrote: post #35

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.

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

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

#49

Post by bcrosby95 »

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.

Yet the only mechanism for this is error prone or relying on mountains of boilerplate.

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

#50

Post by tomc1985 »

knoebber wrote: post #40
tut-urut-utut wrote: post #25

Earlier quoted context omitted.

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.

I agree with this in general, though sometimes incompatibility with popular extensions is an indication that the author isn't following standards.

Asking people to test against all the combinations of browsers and extensions? That's asking a lot
Post reply on HN