A long winded article that really never justifies its headline. Kotlin will soon be generating records in its back end, thereby gaining all the advantages that it's allegedly not getting today.
That feature was released this week with Kotlin 1.5.0.
Java's records, Lombok's data, and Kotlin's data classes
261–270 of 294 posts
Re: Java's records, Lombok's data, and Kotlin's data classes
#262This 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?
The existence of Spring Boot makes Java a very good choice for loads of dev shops. Good balance between features, ease of use, performance and security, not difficult to pick up, and very well documented. In my personal opinion, C# is a superior language these days now that most of .NET has been ported into dotnet core. However, that's only been the case for a few years and before that, Java was in a league of its ow…
Hah this is a great set of analogies. Thanks!
Re: Java's records, Lombok's data, and Kotlin's data classes
#263Re: Java's records, Lombok's data, and Kotlin's data classes
#264Curious question — why do people insist so much on fields being private and there being getters and setters, even when all that getters do is return the field and all that setters do is set it? What kind of problem does this arrangement solve? Why not just use public fields?
In modern Java they can be used to create an accessor function, because Java still does not have syntax for referencing fields in this context.
items.stream().map(Foo::bar)
items.stream().map(i -> i.bar)Re: Java's records, Lombok's data, and Kotlin's data classes
#265Earlier quoted context omitted.
Then you've invented mutability without references/identity. Except those are desired properties for data classes, unlike for value classes which have such semantic difference. Btw Kotlin allow to make immutable Java records too so clear winner.
Not sure what you're getting at. Immutable means exactly that. If you hand out an object, then do a copy change, that change isn't reflected in the object you gave to another method/thread/fiber/etc. Immutability doesn't mean application state never changes; it means that a single reference will always point to memory that hasn't changed.
Parent means basically the difference between identity and primitive/value classes. In Haskell, you’ve only got the latter (maybe you can manage something with lower level controls exposed), that is in a non-haskell syntax new Point(3,2) == new Point(3,2), even though in memory the two object is different.
“Problem” is with records, that they are only shallowly immutable. record Rect(List corners) will readily hand out a “pointer” to a mutable list. It can be solved of course by storing only immutable objects.
What parent may have failed to get from grandparent comment is that the latter likely meant it under the hood, transparently to the user. That is, new Point(3,2) != new Point(3,2) but the JVM can make the object reference the same data, because the field itself is final. Thus a copy can be optimized at the JVM level, while still having identity.
Re: Java's records, Lombok's data, and Kotlin's data classes
#266Earlier quoted context omitted.
Counterpoint: Java programs with memory consumption graphs that have decided sharktooth patterns, which is extremely common.
As opposed to what exactly? How would a C program’s memory graph look with quick bursts of memory-allocation requiring functionality, especially if it is very dynamic in nature? Yeah you can overallocate with memory pools and the like, and there are cases of course where escape analysis can’t help — that’s why Valhalla is in the works for quite some times now. But GC-wise the JVM is far ahead the game, whatever you s…
Value types are essential element of design to me, but this is not widely recognized yet. To me it’d be like saying primitive types are not essential.
Re: Java's records, Lombok's data, and Kotlin's data classes
#267Earlier quoted context omitted.
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?
I'm not sure, but I think I would make a language based on structural typing only, including to allow a structural type to contain names. (Scala actually already has literal types that come close) Think about the following type-level (not runtime) representation for a structural type (tuple): (String -> Integer) And the following for a structural type with where each "member" has a name: (("name" -> String) -> ("age"…
I think nominal types are a must, otherwise you lose most of the benefits of static typing.
Is an Email type the same as a String even though they are the same under the hood? I precisely should not accept it without explicitly casting it, otherwise I would have duck typing. But I agree that explicit structural types can be useful at places.
Re: Java's records, Lombok's data, and Kotlin's data classes
#268Kotlin 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…
The easiest way is with GSON:
https://mkyong.com/java/how-do-convert-java-object-to-from-j...
You would just have to have annotations on the enum names to get the lowercase values in your example json.
Re: Java's records, Lombok's data, and Kotlin's data classes
#269Earlier quoted context omitted.
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.
Values require copying, so depending on the problem it can be worse from a perspective point of view.
Re: Java's records, Lombok's data, and Kotlin's data classes
#270Scala'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.
Scala is usually omitted for one reason or another when Kotlin is compared against Java as a better alternative, which is a shame.
i think Kotlin might be winning over Scala because of better ineroperability with java. https://jelmini.dev/post/java-interoperability-kotlin-vs-sca...