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

101–110 of 294 posts

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

#101

Post by amitport »

slver wrote: post #29
valenterry wrote: post #6

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

I've been thinking about structural vs nominal. As you say, both have use cases. How would you combine both in one language so it's not confusing?

TypeScript!

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

#102

Post by hueho »

The_rationalist wrote: post #15

Kotlin data classes can be used with the JPA contrary to Java records. It's good to encourage immutability, but it is often a misfit and isn't the role of a "data class", they could have added a separate class qualifier immutable that would have been a better separation of concerns, here it's ad-hoc. Kotlin is enabling such immutable support thanks to Java records ironically https://kotlinlang.org/docs/jvm-records.ht…

> Kotlin data classes can be used with the JPA contrary to Java records.

Arguably this is more of an issue of JPA than an strict advantage of Kotlin: JPA was designed at a time where the general consensus was to primarily use mutable data, and was heavily influenced not only by existing Java ORM APIs, but by their implementations.

Kotlin itself supports JPA by the use of a compiler plugin, which is a good enough solution, but nevertheless, not one native to the language. Data classes mostly work by accident, but pretty much any documentation you will find points it to _not_ use them with JPA.

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

#103

Post by shagie »

dtech wrote: post #75
shagie wrote: post #57

Earlier quoted context omitted.

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/j…

GraalVM is excellent in performing escape analysis on objects on the call stack, but it does not prevent the pointer overhead that a JVM array-of-heap-object-references has vs an array-of-structs that e.g. .NET supports [2]. Theoretically it could do hat, but that's just the classic "sufficient smart compiler" strawman [1] [1] https://wiki.c2.com/?SufficientlySmartCompiler [2] https://stackoverflow.com/questions/2966…

My point wasn't so much "can GraalVM do {some optimization}" but rather that the Java Language Specification doesn't say anything about it and that different JVMs have a different set of optimizations.

So "does Java allocate a record in an array directly as some structure of values in the array or as a pointer to a record object?" isn't one that can be answered by looking at Java.

It is an interesting question, and I'd be curious to see someone do a deep dive into the internals of GraalVM to show what can be done.

The other part that trickled out in other comments from the person posing the question about the array of records:

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

and

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

... which, I'd be curious to see how .NET supports an array of struts (that are presumably changing over the lifetime of the array) that is allocated as a global. That sort of use case and the specifics of how it is implemented could make escape analysis give up and you'll see an array on the heap with pointers to records on the heap as they're passed off to different threads (which each have their own stack).

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

#105

Post by zoover2020 »

abledon wrote: post #34

IF you're not on Java 14 yet (70% of industry?[1])... this post shows two other alternatives for Lombok: https://medium.com/@vgonzalo/dont-use-lombok-672418daa819 Autovalue & Immutables [1] https://snyk.io/wp-content/uploads/jvm_2020.pdf pg 5

Unfortunately AWS Lambda doesn't support 14 yet :/

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

#106

Post by the_gipsy »

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 write java and worry about bytes copied?

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

#107

Post by EvilEy3 »

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?

> besides it's mature community/ecosystem/tooling?

Not sure if I should be mad or just ignore you.

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

#109

Post by watwut »

chris_j wrote: post #32
johnthuss wrote: post #4

One of the best things about Records is that they guide you to creating immutable data structures, which Lombok does not. This, along with the reduction of boilerplate, greatly reduces the cognitive load required to understand a lot of code.

Lombok has @Value classes, which I use a lot. Is there something about them that does not guide you to creating immutable data structures?

Lombok increases the cognitive load required to understand and debug the code.

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

#110

Post by mumblemumble »

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.

I think that case classes are roughly equivalent to Kotlin data classes for the purposes of this comparison. In particular, one of the extra features they offer is the ability to make fields mutable. Which, in some cases, may be useful, but also means that they aren't, strictly speaking, transparent carriers of immutable data.
Post reply on HN