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

201–210 of 294 posts

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

#201

Post by pron »

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 don't think they offer more. Deconstructing patterns and "reconstructors" (generalised "withers") are on the way. And Java features are often designed as a complete whole: some of the feature is in the language, some in the core libraries, and some, even, in the VM. In the case of records, they're treated in a special way by the runtime (e.g. in serialisation).

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

#202

Post by AtNightWeCode »

razzm256 wrote: post #78
AtNightWeCode wrote: post #73

Not sure why immutable data structures have surfaced as something important. Typically you never change fields so it is kind of only of academic value if a field in a POD, POJO, POCO or whatever it is called in the specific language actually may change.

There are many good things enabled by immutability, like safer/easier multithreading, value-like semantics for objects. It is definitely not only of academic value.

Typically you use values and not objects for these kind of things so not that much gained.

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

#203

Post by papercrane »

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

> I'm not sure what it's taking about for the "with" feature: ...

The author is referencing possible future work that can build on the current records implementation, and the work Brian Goetz is doing with pattern matching and record deconstruction. Goetz has put together a draft that shows how these could be combined.

https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

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

#204

Post by balefrost »

TJSomething wrote: post #196
crdrost wrote: post #183

Earlier quoted context omitted.

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": "r…

In traditional Java, you're probably using Jackson for your JSON. You can achieve those sorts of results by specifying the classes and type tags in annotations on an abstract Either class to use Jackson's polymorphic serialization feature.

The point of sealed classes is that you have a known number of possible representations. So you can have `when` blocks that exhaustively check all possibilities. Having an open class hierarchy would not work for that purpose.

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

#205

Post by balefrost »

halfmatthalfcat wrote: post #190
throwpupper wrote: post #179

Earlier quoted context omitted.

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

Kotlin's STDLIB collection types are essentially aliases for the Java types. So while the Scala adapters are low-cost, in Kotlin everything's zero-cost.

One other benefit of that is you maintain object identity. I don't think that Scala's wrappers do that.

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

#206

Post by asimpletune »

kerblang wrote: post #181
ernst_klim wrote: post #161

Earlier quoted context omitted.

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

You don’t have to use implicits though, but you’d be super happy they’re there should you ever be in a situation where they’re helpful

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

#207

Post by slver »

vbezhenar wrote: post #191
slver wrote: post #184

Earlier quoted context omitted.

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?

I work as Java developer for the last 10 years, I perfectly understand the amount of software and other things. I don't know much about Python and JS, but I do know that they're not using immutable model, everything is mutable in Python and in JS, so I'm not sure what's your point. The only immutable language I'm aware of is Haskell which is not used widely. Just because JVM is faster than Python or V8 does not mean…

Using immutables doesn’t mean you go full Haskell. Strings are also immutable you know.

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

#208

Post by AtNightWeCode »

the_af wrote: post #199
AtNightWeCode wrote: post #172

Earlier quoted context omitted.

I did not write the original solution...

Precisely: you did not write the original solution, which is where immutability shines. It's a code comprehension tool; it gives you guarantees about code you didn't write. That's a huge boon!

There are no guarantees that it is the same object you get so it is pointless.

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

#209

Post by kaba0 »

grishka wrote: post #166
blacktriangle wrote: post #143

Earlier quoted context omitted.

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.

Not necessarily agree with private fields, but that is not an option for library writers.

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

#210

Post by ernst_klim »

kerblang wrote: post #181
ernst_klim wrote: post #161

Earlier quoted context omitted.

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

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

I don't think implicit counts as "too many features" or as something complex. Basically all it does is finding a canonical value in scope for a hole of certain type.

Post reply on HN