Java's records, Lombok's data, and Kotlin's data classes • Hacker News Board

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

#171

Post by grishka » Fri, May 07, 2021, 7:09 PM UTC

jorblumesea wrote: post #151

grishka wrote: post #140

Curious question — why do people insist so much on fields being private and there being getters and setters, even when all that getters do is return the field and all that setters do is set it? What kind of problem does this arrangement solve? Why not just use public fields?

getters and setters prevent other objects from modifying internal properties in unexpected ways. Having that encapsulation and abstraction is important for maintainable code. Also, getters and setters don't always modify individual values. Imagine a class where we have: private val firstName private val lastName fun returnFullName(): return firstName + lastName

> modifying internal properties in unexpected ways

Except I'm talking about Java classes that store data. They don't do any operations on it, they don't have any internal state, they're more like C structs.

> Also, getters and setters don't always modify individual values.

Of course. But one doesn't contradict the other.

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

#172

Post by AtNightWeCode » Fri, May 07, 2021, 7:09 PM UTC

slver wrote: post #156

AtNightWeCode wrote: post #150

Earlier quoted context omitted.

Fields of an object should typically not change. But yes, I had to make a field of a class immutable some time ago. There was a bug and I could not read the code to figure out were the object was changed. Still, caused by bad code. Same object sent around pretty much everywhere.

So even you, the master of great code, wrote bad code. I guess immutability is worth something then.

I did not write the original solution...

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

#173

Post by kaba0 » Fri, May 07, 2021, 7:09 PM UTC

vbezhenar wrote: post #134

kaba0 wrote: post #59

Earlier quoted context omitted.

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?

That's a theory not happening in practice. In practice Java programs are slow and memory-hungry because of those issues when some people think that it's cheap to create small objects or that escape analysis will solve their issues without verifying that it works for their case.

Most of the world’s server applications would like to disagree with you.

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

#174

Post by scubbo » Fri, May 07, 2021, 7:09 PM UTC

xenomachina wrote: post #162

AzzieElbab wrote: post #66

Earlier quoted context omitted.

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

What annotations are you referring to?

I'm not the person you were asking, but, presumably, Lombok's annotations.

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

#175

Post by AzzieElbab » Fri, May 07, 2021, 7:10 PM UTC

xenomachina wrote: post #162

AzzieElbab wrote: post #66

Earlier quoted context omitted.

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

What annotations are you referring to?

Lomboks. Seriously, scala case classes are like the very first thing people start using when learning the language. Scala3 enums are even more straightforward

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

#176

Post by kelnos » Fri, May 07, 2021, 7:11 PM UTC

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 don't know if the JVM developers have actually implemented this, but since records are immutable, there's no reason why a copy couldn't share memory between the instances.

The major downside is that could ruin cache locality and make passing the instance across a FFI boundary require a copy.

Another optimization would be that the JIT (or even perhaps javac) could notice cases where you make a copy (with one field changed) of a record and then never use the original reference again. If the JIT (or javac) can prove that no other bit of code holds a reference to the original record, it can reuse and mutate the original one instead of making a copy. I don't know if this optimization is or will be implemented, of course.

Either way, I expect the overhead you mention ends up being worth the benefits of immutable data. (That's been my experience using Scala, anyway.)

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

#177

Post by lowbloodsugar » Fri, May 07, 2021, 7:11 PM UTC

smoldesu wrote: post #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?

>Are there any real advantages to using Java in 2021, besides it's mature community/ecosystem/tooling?

It's fast: C fast in most cases. It can use a lot of cores and memory with minimal effort from developers. It has great tuning parameters for things like GC. We hit a cliff at about 150GB heap, tuned it, and now we're at 300GB. It's "good-enough" type safe. Java grows with you.

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

#178

Post by jhgb » Fri, May 07, 2021, 7:13 PM UTC

jandrese wrote: post #148

anonymoushn wrote: post #64

Earlier quoted context omitted.

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

You are chasing nanoseconds with a garbage collected language?

Those nanoseconds tend to add up.

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

#179

Post by throwpupper » Fri, May 07, 2021, 7:13 PM UTC

kelnos wrote: post #167

adambatkin wrote: post #111

Earlier quoted context omitted.

Lombok and Kotlin are both much easier to integrate into existing Java applications and libraries than Scala.

I don't see how Kotlin is easier to integrate into an existing Java app than Scala is. They both require adding new dependencies and changing your project build config, and require developers who know the respective new language. That's... about it. They both offer similar levels of interop with Java libraries. If you want to assert that finding Kotlin developers is easier or that Kotlin is an easier language to lear…

What about the fact that Kotlin collections are fully interoperable with Java collection? That makes the transition significantly easier.

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

#180

Post by kasperni » Fri, May 07, 2021, 7:17 PM UTC

loukrazy wrote: post #11

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.

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

Yes, just add 'primitive' before record in the declaration.