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

161–170 of 294 posts

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

#161

Post by ernst_klim »

aero142 wrote: post #58
halfmatthalfcat wrote: post #23

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.

> except the problem of too many features

Scala is a pretty simple, concise and coherent language though. Never understood why people deem it has too many features, I write it professionally and never felt so.

At least comparing it to C, C++, Python. Java may be more simple, but you have tons of features added with metaprogramming via dozens of annotations generating lots and lots of boilerplate, Lombok and Spring are examples of that.

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

#162

Post by xenomachina »

AzzieElbab wrote: post #66
aero142 wrote: post #58

Earlier quoted context omitted.

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

What annotations are you referring to?

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

#163

Post by lowbloodsugar »

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?

Freedom to change.

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

#164

Post by krzyk »

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.

GC is there for a reason, unless you do HFT, use it to your advantage.

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

#165

Post by kaba0 »

slver wrote: post #141
kaba0 wrote: post #129

Earlier quoted context omitted.

False. The JVM already does quite a good job with escape analysis, and record types just add extra semantic information to potentially further improve the situation.

What precisely of what I said is “false”?

the JVM does something of the sort right now.

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

#166

Post by grishka »

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

This protects you from changes to the internal representation of state in the future. Direct field access totally blows away encapsulation.

So, uh, do a usage search before changing stuff? You'll have to, anyway.

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

#167

Post by kelnos »

adambatkin wrote: post #111
halfmatthalfcat wrote: post #23

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.

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 learn, sure, that might be the case (I really don't know), but that's not really an integration task.

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

#168

Post by kaba0 »

jandrese wrote: post #144
kaba0 wrote: post #129

Earlier quoted context omitted.

False. The JVM already does quite a good job with escape analysis, and record types just add extra semantic information to potentially further improve the situation.

Counterpoint: Java programs with memory consumption graphs that have decided sharktooth patterns, which is extremely common.

As opposed to what exactly? How would a C program’s memory graph look with quick bursts of memory-allocation requiring functionality, especially if it is very dynamic in nature? Yeah you can overallocate with memory pools and the like, and there are cases of course where escape analysis can’t help — that’s why Valhalla is in the works for quite some times now.

But GC-wise the JVM is far ahead the game, whatever you see is likely better than the same functionality would be under JS, Python, C#, Go, etc (though the latter two do have value types/structs already so they can at some place manually do the “escape-analysis”. But not every problem requires/can use value types either)

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

#169

Post by kelnos »

cs-szazz wrote: post #31

I'm not sure what it's taking about for the "with" feature: https://nipafx.dev/java-record-semantics/#with-blocks In Kotlin data classes, it's already implemented (just called copy) https://kotlinlang.org/docs/data-classes.html#copying

The annoying thing about Java here is that it doesn't have default argument values, and doesn't allow you to name your arguments in function calls.

In Scala (I don't know Kotlin, but I assume it's similar) you could easily implement a copy() method yourself (and many people do if they need a case-class-like thing but can't use a case class) that behaves identically to the copy() method provided by a case class.

But the semantics of that copy() method require default argument values, and the ability to call functions using named arguments. Java doesn't have either of those, so instead of adding those features (I can understand the former being controversial), I guess the plan is to add entirely new syntax just for records, which IMO is a huge shame.

But it appears the "with" syntax is far from finalized, so it's possible they'll do something better.

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

#170

Post by eklavya »

Someone wrote: post #132
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...

Java compilers are getting more and more advanced, but I don’t think they will ever become the magical “sufficiently advanced compiler” that produces code that’s as good as humans _could_ (but often won’t, because of time constraints) write. I don’t think anybody fully disagrees with that. At least, I haven’t heard people claim int can be removed from the language because a good compiler can produce identical code fo…

I could be wrong but I don’t think dart has ints, I think it only has objects.
Post reply on HN