Re:Java's records, Lombok's data, and Kotlin's data classes
by kaba0 on Friday May 07, 2021 @01:05PM
(#27078179)
Or you know, the JIT will trivially optimize away the old class if it is reassigned to the same variable, as you would use it inside a loop. How do you think the litany of FP languages work? Like Haskell, Scala, Clojure?
[ Parent
| on HN ]
Re:Java's records, Lombok's data, and Kotlin's data classes
by slver on Friday May 07, 2021 @02:10PM
(#27078907)
It can be done in theory, but the JVM does nothing of the sort right now.
Re:Java's records, Lombok's data, and Kotlin's data classes
by kaba0 on Friday May 07, 2021 @02:19PM
(#27079031)
False. The JVM already does quite a good job with escape analysis, and record types just add extra semantic information to potentially further improve the situation.
Re:Java's records, Lombok's data, and Kotlin's data classes
by jandrese on Friday May 07, 2021 @02:43PM
(#27079359)
Counterpoint: Java programs with memory consumption graphs that have decided sharktooth patterns, which is extremely common.
Re:Java's records, Lombok's data, and Kotlin's data classes
by kaba0 on Friday May 07, 2021 @03:08PM
(#27079694)
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 see is likely better than the same functionality would be under JS, Python, C#, Go, etc (though the latter two do have value types/structs already so they can at some place manually do the “escape-analysis”. But not every problem requires/can use value types either)
Re:Java's records, Lombok's data, and Kotlin's data classes
by slver on Saturday May 08, 2021 @02:55AM
(#27084619)
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
by slver on Friday May 07, 2021 @02:41PM
(#27079332)
What precisely of what I said is “false”?
Re:Java's records, Lombok's data, and Kotlin's data classes
by kaba0 on Friday May 07, 2021 @03:02PM
(#27079615)
the JVM does something of the sort right now.
Re:Java's records, Lombok's data, and Kotlin's data classes
by slver on Friday May 07, 2021 @04:43PM
(#27080661)
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
by vbezhenar on Friday May 07, 2021 @02:31PM
(#27079194)
That's a theory not happening in practice. In practice Java programs are slow and memory-hungry because of those issues when some people think that it's cheap to create small objects or that escape analysis will solve their issues without verifying that it works for their case.
Re:Java's records, Lombok's data, and Kotlin's data classes
by kaba0 on Friday May 07, 2021 @03:09PM
(#27079713)
Most of the world’s server applications would like to disagree with you.
Re:Java's records, Lombok's data, and Kotlin's data classes
by slver on Friday May 07, 2021 @03:23PM
(#27079892)
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?
Re:Java's records, Lombok's data, and Kotlin's data classes
by vbezhenar on Friday May 07, 2021 @03:30PM
(#27079968)
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 that it's OK to slow it down with immutables.