Value Objects in Valhalla
Вставка
- Опубліковано 5 чер 2024
- Presented by Dan Smith - Senior Developer (Java Platform Group - Oracle) during the JVM Language Summit 2023 (Santa Clara CA).
Project Valhalla ➱ openjdk.org/projects/valhalla/
Early-Access builds ➱ jdk.java.net/valhalla/
Development ➱ github.com/openjdk/valhalla
Follow along Expert Group design discussion ➱ mail.openjdk.org/pipermail/va...
Implementation & usage discussion ➱ mail.openjdk.org/pipermail/va...
Design feedback (write-only) ➱ valhalla-spec-comments@openjdk.org
Make sure to check the • JVM Language Summit 2023 playlist.
Tags: #JVMLS #OpenJDK #Java #Valhalla - Наука та технологія
I can't wait to get my hands on value objects and eventually primitive generics!
Java is seriously handicapped for high performance libraries because of the missing generics for primitives. Everything feels hacky without it. the speed up given by primitive collections like fastutils is an order of magnitude but is not a clean API as every primitive type and combination is a separate class.
They really should have addressed that first. As it has a massive implication on library API. performance can be handled later.
Ooo, this is being bookmarked for after work :D
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. 🍃
Same thing for virtual threads...
Climate hysteria isn't real. But saving energy is of course a good thing
Well, it does also require those billions of devices getting upgraded versions and often also new code, so there's that to keep in mind..
Damn Java will have a come back! A tip: remove the use of 'implicit' and just use the keyword 'default'.
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")
@Java what do you think about it?
@@alexk4062 could you be more precise what exactly will be broken?
@ndrvsk Integer can be null at the moment. You will restrict that.
Also, they plan on String! Soo for the sake of a String and an Integer feeling the same, i'd say that what they are proposing is awesome
29:39 What he says contradicts the example in the slide, which is actually a really bad situation (empty: false, value: null).
yes, in reality, the Optional class is implemented using a single field carying the value or null, which is more appropriate.
The primitive‑specialised `Optional` classes `OptionalInt`, `OptionalLong`, and `OptionalDouble` use (isPresent: boolean, value: int/long/double).
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 ❤
A String field is like any other Object reference. The String class itself won't be a value class or flattened in memory as it doesn't have a static size for all instances.
@@bourne2program What varies the size between String instances? I see it has 4 fields: byte[] value, byte coder, int hash, and boolean hashIsZero, and all of those are statically sized.
@@zhamed9587 Two Strings cannot share a one (common) byte[] array because they (Strings) are immutable.
Maybe I missed it in the JEP. But for the implicit constructor can we have user defined default values?
No. I've tried to convince the Valhalla Experts Group otherwise, but haven't made much progress.
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...
Upon reading the JEP again it seems as though value classes may have an abstract superclass, which is confusing because it also states any abstract class with an instance field is implicitly an identity class. Why would that be necessary even if the fields were final?
So I am wondering if records would be good candidates as value classes....🤔
Records are between Objects and Values
They are indeed candidates for value types, they are implicitly final and their fields are final, equals and hash code are component based.
Records DO HAVE identity, value objects don't, so they are different. Domain Driven Dessign shows us what are Value Objects for and what Entitys (records) are for
@@diegoshevek5927 I will certanly look add DDD, but quotting from the JEP daft for value objects: "Records are often good candidates to be value classes, because their fields are already required to be final.". I would imagine as you can say value class Foo, you could also do value record Bar
@Records and Value Objects have immutable fields (final fields), that's because it's always safer and easier to program against immutable objects. A record has an identity; that for Java means that records automatically includes an override of equals(...) and hashCode(). With Value Objects you don't need equals and hashCode
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.
ok dude
No, thank you.
In C/C++ and C#, structs are mutable by default.
Because of the close adjacency of Java to the C language family, it would be confusing to name value objects "structs" when they have such different semantics from structs in the C language family.
"oop mindset" - dude, its java its meant to be oo. If you dont like it change your language!
@@sandrodelacruz8125 I'm no longer using java for personal projects.I use nodejs and python professionally since 2021. I am thankful that I didn't have to debug 250 layers of abstract classes since my last java mission
Nobody will ever use this feature.