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
Java's records, Lombok's data, and Kotlin's data classes
211–220 of 294 posts
Re: Java's records, Lombok's data, and Kotlin's data classes
#212Kotlin 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…
Re: Java's records, Lombok's data, and Kotlin's data classes
#213Earlier 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.
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
#214Earlier 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?
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
#215Earlier 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.
Re: Java's records, Lombok's data, and Kotlin's data classes
#216Earlier 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?
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
#217Earlier 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?
Re: Java's records, Lombok's data, and Kotlin's data classes
#218Earlier 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
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
#219Earlier quoted context omitted.
What precisely of what I said is “false”?
the JVM does something of the sort right now.
Eventually with some more evolution. But not yet.
Re: Java's records, Lombok's data, and Kotlin's data classes
#220Earlier 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.
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.