Live data from Hacker News

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

nipafx.dev

211–220 of 294 posts

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

#211

Earlier quoted context omitted.

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

The ancestors of your comment mention Kotlin, not Lombok, which is why I asked. Kotlin's data classes are probably the analog to Scala's case classes, and they do not require annotations.

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

#212

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

Sealed classes are (most likely) going to be in the next version of Java, Java 17: https://openjdk.java.net/jeps/409

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

#213

Earlier quoted context omitted.

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 mean, you do realize that you're writing Java code right? If you want ultimate low level optimization and control then you're already about ten miles too far downstream to make that turn. Also, I'm guessing the copy overhead is more than offset by the JVM being able to do better optimizations around these data structures.

Structs with mutable fields is hardly “ultimate low level optimization”, it’s something a lot of programmers still use as a matter of course. (I say this as a fan of immutable data!)

Ultimate low-level optimization in Java would be more like packing your structure into arrays of integers - which is something people actually do in Java. Just because you’re using Java doesn’t mean you don’t want your code to run as fast as possible.

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

#214
post #76

Earlier quoted context omitted.

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?

> besides it's mature community/ecosystem/tooling

How could you not see this as an incredible technical advantage in almost any context?

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

#215

Earlier quoted context omitted.

> 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 can use Scala without introducing implicits and even if you have to interopt with a library that does require them, it's quite easy to learn how to use them. It's also easy to abuse them but then that's not really Scala's problem. They are changing implicits in Scala 3 though with the "given" keyword which is more ergonomic.

Scala can't let go of implicits as they're a fundamental part of the language. I just don't believe this Scala 3 fudge to give the impression implicits are not alive and well beneath the surface.

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

#216

Earlier quoted context omitted.

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

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

I have a policy of saying whether if is true or false.

That said you should take his word for why it was designed that way and my word as an historical account of why I did that in 2005-2015.

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

#217
post #76

Earlier quoted context omitted.

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?

If you must have a specific language level technical advantage over C++/Rust, its the incredible GC algorithms available to you while you are (mostly) stuck with simple arena collectors in C++/Rust land.

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

#218

Earlier quoted context omitted.

> 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

Doesn’t a monad or for comprehension use implicits to find the right CanBuildFrom?

Are you suggesting to use scala without using for comprehensions? Or do you mean you don’t need to write your own?

It’s been a long time since I wrote scala, so may be getting it wrong.

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

#219
post #165
post #141

Earlier quoted context omitted.

What precisely of what I said is “false”?

the JVM does something of the sort right now.

Every time you rebuild a record you run through its constructor. I doubt this can be optimized the same as with a plain C struct.

Eventually with some more evolution. But not yet.

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

#220

Earlier quoted context omitted.

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.

Scala has the full suite of Java collections without any conversion or overhead whatsoever.

But it also has Scala collections. With scala collections you get the full power of the Scala type system, as well as a much richer and full featured collections api. So most scala programmers won't bother with java collections unless they have specific java interop requirements.

The Scala adapters are merely ways of converting java collections to scala collections and vice versa.

Post reply on HN