Java's records, Lombok's data, and Kotlin's data classes • Hacker News Board

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

#221

Post by reom_tobit » Fri, May 07, 2021, 9:03 PM UTC

AtNightWeCode wrote: post #122

reom_tobit wrote: post #92

Earlier quoted context omitted.

Keyword being “may”. Guarantees are nice. Especially if objects are going to be passed around every which way from Sunday. It allows you to better reason about what could happen, and where. Java has taken a while to get there, but I’m glad that they have finally.

Well, if you pass around objects and change their state records will not help. People who does this are already using immutable frameworks in Java to clone and change some field and then pass it along.

Sure, things have been bolted on top of Java to allow this to happen. People have made use of them.

Java now has built in support for these things, so no longer will developers rely on third-party solutions.

This is great for the Java world, and for any languages that are being built on top of the JVM by extension.

I would politely disagree with your characterisation of it being just academic, as an engineer I find it incredibly exciting. Admittedly, my bar is pretty low for excitement these days.

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

#222

Post by kjeetgill » Fri, May 07, 2021, 9:17 PM UTC

ernst_klim wrote: post #210

kerblang wrote: post #181

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.

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

I only worked in Scala briefly so maybe it's coming from Java habits, but implicits were huge pain. When first reading through code you don't really know if that function call you eyed over really has the params you think it does. It makes it WAY harder to track what's derived from what.

Either way, the local Scala guru there said the Scala community was starting to get over implicits.

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

#223

Post by dtech » Fri, May 07, 2021, 9:23 PM UTC

shagie wrote: post #103

dtech wrote: post #75

Earlier quoted context omitted.

GraalVM is excellent in performing escape analysis on objects on the call stack, but it does not prevent the pointer overhead that a JVM array-of-heap-object-references has vs an array-of-structs that e.g. .NET supports [2]. Theoretically it could do hat, but that's just the classic "sufficient smart compiler" strawman [1] [1] https://wiki.c2.com/?SufficientlySmartCompiler [2] https://stackoverflow.com/questions/2966…

My point wasn't so much "can GraalVM do {some optimization}" but rather that the Java Language Specification doesn't say anything about it and that different JVMs have a different set of optimizations. So "does Java allocate a record in an array directly as some structure of values in the array or as a pointer to a record object?" isn't one that can be answered by looking at Java. It is an interesting question, and I…

The point is those optimizations are not here now, and haven't been there for the last 25 years. Hand-waving them away as theoretically possible is dishonest. We're 25 years into the most popular programming language's lifetime and the most advanced VM available only recently learned good escape analysis. It isn't easy.

> which, I'd be curious to see how .NET supports an array of struts (that are presumably changing over the lifetime of the array) that is allocated as a global.

Very easy. An array-of-structs (which can still be on the heap mind you) will just be a continuous block of memory. This is totally independent of any locking and synchronization.

For example in a class with 2 32-bit fields, and an array of objects a b object-ref array will look like: [p_ap_b], p being a pointer to [a_0a_1] or [b_0b_1]. A struct-array will look like [a_0a_1b_0b_1].

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

#224

Post by Someone » Fri, May 07, 2021, 9:53 PM UTC

eklavya wrote: post #170

Someone wrote: post #132

Earlier quoted context omitted.

Java compilers are getting more and more advanced, but I don’t think they will ever become the magical “sufficiently advanced compiler” that produces code that’s as good as humans _could_ (but often won’t, because of time constraints) write. I don’t think anybody fully disagrees with that. At least, I haven’t heard people claim int can be removed from the language because a good compiler can produce identical code fo…

I could be wrong but I don’t think dart has ints, I think it only has objects.

https://api.dart.dev/stable/2.6.0/dart-core/int-class.html:

“Classes cannot extend, implement, or mix in int.”

https://api.dart.dev/stable/2.6.0/dart-core/num-class.html:

“It is a compile-time error for any type other than int or double to attempt to extend or implement num.”

⇒ it seems that, technically, you’re right. int is an object in Dart. At the same time, it’s a restricted type of object.

So restricted that I think it is aan object only in name/at compile time.

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

#225

Post by AtNightWeCode » Fri, May 07, 2021, 9:53 PM UTC

slver wrote: post #139

AtNightWeCode wrote: post #136

Earlier quoted context omitted.

The standard way to do it is to mutate clones as always in Java. Typically by use of libraries that provide this. You really need very bad code to have to think about if objects are mutable.

Apparently you don’t know most immutable structures are optimized for modified cloning in ways mutables aren’t.

This is Java.

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

#226

Post by AtNightWeCode » Fri, May 07, 2021, 10:13 PM UTC

slver wrote: post #186

AtNightWeCode wrote: post #172

Earlier quoted context omitted.

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.

You are just too stupid. I hope you are not immutable.

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

#227

Post by AtNightWeCode » Fri, May 07, 2021, 10:17 PM UTC

reom_tobit wrote: post #221

AtNightWeCode wrote: post #122

Earlier quoted context omitted.

Well, if you pass around objects and change their state records will not help. People who does this are already using immutable frameworks in Java to clone and change some field and then pass it along.

Sure, things have been bolted on top of Java to allow this to happen. People have made use of them. Java now has built in support for these things, so no longer will developers rely on third-party solutions. This is great for the Java world, and for any languages that are being built on top of the JVM by extension. I would politely disagree with your characterisation of it being just academic, as an engineer I find i…

I have done Java for 25 years and never felt any need for records. There are so many issues...

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

#228

Post by giaour » Fri, May 07, 2021, 11:03 PM UTC

giaour wrote: post #128

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

"With" doesn't exist in Java, but it was introduced in C# 9.0 as part of the .NET implementation of records: https://devblogs.microsoft.com/dotnet/c-9-0-on-the-record/#w... I think the author is more saying that a "with" operator would fit into Java record semantics but might not be compatible with Lombok @Data classes or Kotlin data classes (though it looks from your link that Kotlin actually does have something ver…

Not sure why this is getting downvoted; if you look at the hypothetical “with” syntax in the original blog post, it is clearly borrowed from the C# implementation.

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

#229

Post by ragnese » Sat, May 08, 2021, 12:13 AM UTC

ernst_klim wrote: post #161

aero142 wrote: 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…

Exactly this. Java-the-language is so simple that Java-in-practice is disgustingly littered with verbose patterns to accomplish really basic abstraction concepts, annotations that may or may not work at runtime, and runtime reflection with unsafe casting because of type-erased generics.

Java codebases are way scarier than Scala.

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

#230

Post by joshlemer » Sat, May 08, 2021, 12:54 AM UTC

diroussel wrote: post #218

asimpletune wrote: post #206

Earlier quoted context omitted.

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.

CanBuildFrom is gone in the 2.13 collections rewrite