Value Objects in Valhalla  

I can't wait to get my hands on value objects and eventually primitive generics!

Ooo, this is being bookmarked for after work :D

Damn Java will have a come back! A tip: remove the use of 'implicit' and just use the keyword 'default'.

Maybe little out of the box thought, but i can only imagine the impact this project can have in regards of energy and computational resource consumption when rolled out to all of the Billions of devices and servers running Java apps and systems. Climate saving IT action of the year. 🍃

I'm sure these changes will shatter the Java world. As a Java developer I'd say that I would be nice I there were generalized approach of nullness. it's really hard to maintain Domain model, when all object can be null In most of the cases, null is more than an rare case of state of the object. That would be nice for "Value object" all fields will be required and only if it's optional - you need to say that it's required, e.g. field String name - for value object would be required, and field String? name - would allow null values. Of course - as an alternative there might be String! or String?, but I can imagine a class of 20 of fields and everywhere there would be String! name, Point! position ... etc So, long story short - imho, best solution - required not null values for Values objects and madatory '?' operator to define optional objects What also can be done to make our live easier: - Builders for Records/Value object classes- just to remove lombok Builder and toBuilder, since it produces too much of heap overhead, but considering that really convenient - everyone uses it - As an alternative for Builders it can be done as a Named method arguments not only for constructors, but also for methods - With-ers for making changes - That's would be nice to see that field is required and you must pass the value during Compilation time, not only Runtime - For '?' operator that would be nice if it behaves the same as Optionals, e.g. for String? name -- name.orElse("defaul-name")

29:39 What he says contradicts the example in the slide, which is actually a really bad situation (empty: false, value: null).

Looks good!

Could a sealed value interface still be flattened? The JVM knows all subtype sizes and may therefore always allocate the maximum footprint alongside a class pointer. At least if the sizes are similar as to not drive up the overhead.

Yay Valhalla

So it *does* support String as fields! I'm very much looking forward to Valhalla ❤

Maybe I missed it in the JEP. But for the implicit constructor can we have user defined default values?

Great to see the progress. However I must wonder about the rationale behind preventing abstract value classes. I realize it's impractical to flatten any non-final value type due to unknown size - however it's still desirable to abstract over fields and methods, with the added benefit of more performant access/dispatch. Flattening can then be applied to any final subtype. Please let me know what I'm missing here...

So I am wondering if records would be good candidates as value classes....🤔

Valhalla wen, 10 years

IMPLICITLY final fields? I thought the immutability limitation was just part of the early revision, but if the fields are implicitly final, then it's baked in as a permanent language flaw.

mental health.

just call it a struct for god sake. no incompatibility with identity object since it's not an object. get rid of the oop mindset.

Nobody will ever use this feature.