Value Classes Still Need Compiler Sympathy

dist-epoch

Since being created, the Java pitch was "don't worry about low-level stuff like value/reference classes, a Sufficiently Smart Compiler will automatically pick the best option given your code and runtime profiling". What changed, why suddenly they adopt C++ features they explicitly excluded? https://wiki.c2.com/?SufficientlySmartCompiler

DarkNova6

Good technical overview, and I fully agree with the conclusion's sentiment at the end: ``` Declaring a value class is first and foremost a semantic decision. It tells our fellow programmers that its instances are defined entirely by their state and do not need identity. That clearer model is valuable in itself! The JVM’s additional freedom to optimize how those values are represented is a welcome bonus. ``` Many developers seem to think that "go value go broom", but the truth is much more nuanced and the idea should not be to think about "but performance" but to think about the nature of your underlying data. At the very least this integrates some core DDD lessons directly into language. I'm glad tearing isn't turned on by default exactly for this reason. Java was always a language that geared itself towards making libraries easy to use, putting much faith in the library author and strong encapsulation. Now, experts can gain significantly more performance from the JVM, while more humble programmers are avoided from creating bugs they will not expect.

ferrule

Escape analysis doing the heavy lifting here. Until it's fully reliable you're still guessing at allocation.

pan_lid

JVM escape analysis has always been hit or miss. Nice to see it getting more predictable.

aatd86

Of course they do, regardless of the language. That is why we have things such as string interning for instance. :)

pfdietz

Common Lisp has some value types, specifically numbers and characters. Any implementation is allowed to copy these objects at any time. For this reason the EQ function should not be used on numbers or characters, as the results may be unpredictable. The comparison function EQL should be used normally in its place. (Integers and characters also are often represented by "immediate" values that reside inside what would otherwise be a pointer; for these EQL and EQ always do the same thing. But bignums and larger floats allocated on the heap can be different.) It would be interesting to extend Common Lisp to have types that operate similarly. For example, structures that are not compared by object identity but by EQL of their fields. I presume these are the value types being discussed here for Java. One nice thing about value types is they play well with distributed computing. Serialize/deserialize and the values stay the same; no need to have references to objects sitting off in another computer.

dullcrisp

I’m not sure I fully understand why the compiler can’t derive the specialized apply method in this case. I guess I follow the technical reason that the interface doesn’t override the method so there can’t be a specialized version of it. But that’s only visible through reflection right? Not in the direct language semantics?