Live data from Hacker News

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

nipafx.dev

181–190 of 294 posts

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

#181
post #58

Earlier quoted context omitted.

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 ar…

> Never understood why people deem it has too many features

I'll start with one (key)word: `implicit`

I agree with your distaste for metaprogramming though.

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

#182
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”.

Sure, but I think that's still important that it's possible. And if it doesn't get implemented, the reason may be because JVM developers have done the work to figure out that in the real world the optimization doesn't buy all that much.

Regardless, if you care about performance enough (via actual benchmarks) that you know that you really need some data to be guaranteed to be stack-allocated structs, then you probably shouldn't be using Java (or any GC'd language?) in the first place. Records don't change that calculus.

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

#183

Kotlin data classes can use Java records as their implementation if running on JVM, so it’s not like you have to choose one or the other. https://kotlinlang.org/docs/jvm-records.html#declare-records...

This is great news!

I was also kind of surprised to see the article talking about algebraic data types... table stakes for ADTs is sum types and I have missed them considerably in the Java ecosystem.

Kotlin has something like them with sealed classes, although I'm a newcomer to the Kotlin and Spring Boot ecosystem so I don't see explicitly how I make some simple case like JSON

    {"type": "left", "abc": 123}
    {"type": "right", "def": "456"}
turn into some structure like:

    sealed class EitherTest {
        data class Left(val abc: Long): EitherTest()
        data class Right(val def: String): EitherTest()
    }
rather than the hacky version that you have to do in relational databases and Java which don't support such things,

    enum class EitherType { LEFT, RIGHT }
    data class EitherTest(val type: EitherType, val abc: Int?, val def: String?)
Like I’m not saying that there’s no way, I’m sure there’s a way... just that the ecosystem seems so hesitant to embrace sum types that like the above sealed class is widely viewed as a hack and there is no statement about “here is how you actually use sum types for everything in your Spring application with Kotlin.”

Was gonna give the choose-your-own-adventure example of why sum types are handy and how you have to kind of hack around them with inheritance when you don't have them but it occurs to me that anyone who has stuck with this comment this far probably already has some familiarity with this?

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

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

Java isn’t perfect. But you underestimate the amount of software written in it. Or even things like Python and JS which are a lot more basic but have similar elements in regards to their memory model. What do you use?

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

#185
I believe the article focuses too much on "perceived/future" benefits of records, while ignoring the actual benefits that Lombok & Kotlin data classes provide today.

For example, article does not mention lombok @Builder and Kotlin `copy` when talking about boilerplate. Boilerplate is not just about application code, it's also about test code!

We have dozens of entities, and when unit testing them – always having to construct the COMPLETE record with all attributes from scratch is a pain. Nested records things worse. We now have all data classes as @Value+@Builder, and test factories provide consistent builders which the actual test cases can chain, override and use. This is possible in Lombok & Kotlin, but not in Record.

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

#186
post #156

Earlier quoted context omitted.

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

So you reckon we only need immutability if two or more people have to work on code. Ok.

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

#187
post #76

Earlier quoted context omitted.

> besides it's mature community/ecosystem/tooling Thats the answer. And its a really good one. The only other languages with the same or better breadth and depth have their own reasons to avoid them like the plague (e.g. C/C++ footguns, difficulty managing large-ish codebases without types)

IKR. The question framing is almost like: is there any other reason to use Java except all the most important and good reasons?

I meant it more on a language level. It has a great network of support, no doubt credited to it's long legacy, but what technical advantages would it provide over writing a program in a language like C++ or Rust? Is it all creature comfort, or does it have some hidden advantage that I can't see?

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

#188

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

My general rule (in Scala) is that if I need a tuple larger than two or three elements, I'm better of writing a case class. Tuples get unreadable real fast.

I think tuples are an essential language feature (and it's ridiculous that Java doesn't have them yet), but I think they're often way overused.

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

#189

Earlier quoted context omitted.

I had the same question -- why accessor methods instead of making the fields public, but final. If anything, it seems like a layer of indirection. The only answer that makes any sense is this one from Brian Goetz.[1] Namely, that it's a workaround to support mutable fields of otherwise immutable objects. To be honest, allowing you to override the methods on an immutable, auto-generated class to inject custom accessor…

> why accessor methods instead of making the fields public, but final. The best explanation I have is that it is: - a convention that seemed like a good idea for many people at the time, it even has a name: Javabeans - it allows for a standard non magic way to add logic to be run when reading or updating fields - in a time where source control tools and Java refactoring tools where not as developed as they are today…

Thanks for your speculation, but I'd rather take Brian Goetz's word for it. He is, after all, one of the architects of the Java language and the records feature in particular.

...Unless you're Brian Goetz's alt account?

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

#190
post #167

Earlier quoted context omitted.

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.

I believe Scala's are as well, this seems to be a pretty complete list:

https://www.scala-lang.org/api/2.13.5/scala/jdk/javaapi/Coll...

Post reply on HN