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. 🍃
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.
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")
@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
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?
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
Рік тому+2
@@diego.alcantara.rosario 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
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.
I don't understand why you would make value objects immutable. If I cannot use a flattened array of value objects to hold both input and output data then they seem pretty useless. Consider this situation: value class Point() { public double x; public double y; } Point[] array = new Point[1000000]; // Flattened value class array allocates 1000000*2 double precision values in continuous memory // Use array to hold results of calculations or read/write data array[0].x = 1; array[0].y = 1; ... By "immutable" do you mean that I can't change the x and y values as shown above, or do you mean that I can't reassign an element of the array? If I can't reassign array elements then that is expected and what I want, but if I can't change the x and y values of each point then this type of value object is useless.
The fields of the value type are immutable, your array is not a value type it's an identity type. However it is an array of value types thus it can be represented as a contiguous space in memory. I think they will also add value type arrays, but for those you would lose the ability to dynamically resize them, and they would be immutable, but with them you could be able to compose larger, more complex value types - I think this is where the future library work mentioned at the end would go, as this also applies to all collections.
@@sporegnosis Thank for the reply! So I still don't see the usefulness of a value class object if primitive fields are immutable. I can understand that object fields or value object fields must be immutable, but not primitive fields. If those fields are immutable that means when I create a large value array I must already have the data to initialize them already loaded into memory. That defeats the purpose of having them in the first place. It also doubles the memory required. I have always been taught to keep data in large continuous memory blocks to reduce page swapping when doing high performance computing like computational fluid dynamics (CFD) or finite element method solutions (FEM), However those calculations also require large blocks of memory to hold results, and states. I can't use immutable objects to hold results if I can't change their field values.
@@sstevenson638 It is exactly because because of the reason you state at the end of the reply. identity objects are not stored in a contiguous memory location, only their pointers are because identity objects are always stored in the heap - check the intro of the video and read about how objects are stored in the JVM. But you still misunderstand it: identity arrays will still be mutable, and with valhalla you will get the ability to create your own value objects as elements into that array that will be immutable. So if you are storing a point class in an array and wish to change it, you need to store that entire point value object again as an element, no matter how many fields it has. The feature is about performance gains, to bring the JVM closer to C and C++, and especially the work with value objects on the stack (which now supports only single primitive values) is going to be huge - it has nothing to do with new functionality per se. If you are happy with the performance of your java applications on the desktop or the cloud then this is not for you.
@@sporegnosis Is there a technical reason value objects need to be immutable or is this just a design principal? I have been looking into C# and it already has mutable value classes. My roots are in FORTRAN, C, C++, and Java. I have never used C# but I think they have made some good design decisions for folks like me interested in high performance scientific/engineering computing.
@@sstevenson638 Reasons: 1. by giving up Identity, it's just the data - there is no actual storage location logicaly, so no need to invent one or pretend that there's one. 2. you give explicit and permanent permission to the runtime to pass the value type from the heap to the stack and back, and even move it in any memory space at will, without affecting user code, or even store identical values just once like with strings. 3. it's not needed, as value types are meant for relatively small objects 4. Similar to 2 above, the value types can be passed as parameters and return values by data copy and remain consistent 4. immutability makes the object state completely atomic - as required by most of these operations and optimizations.
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.
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.
@@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
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. 🍃
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..
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).
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.
Looks good!
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?
@@dd2ljf932 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
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?
since when are primitives not mutable? 4:32
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
@@diego.alcantara.rosario 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
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.
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.
Valhalla wen, 10 years
Soon 11... by the time it comes out, we'll all be in Valhalla...
I don't understand why you would make value objects immutable. If I cannot use a flattened array of value objects to hold both input and output data then they seem pretty useless. Consider this situation:
value class Point() {
public double x;
public double y;
}
Point[] array = new Point[1000000]; // Flattened value class array allocates 1000000*2 double precision values in continuous memory
// Use array to hold results of calculations or read/write data
array[0].x = 1;
array[0].y = 1;
...
By "immutable" do you mean that I can't change the x and y values as shown above, or do you mean that I can't reassign an element of the array? If I can't reassign array elements then that is expected and what I want, but if I can't change the x and y values of each point then this type of value object is useless.
The fields of the value type are immutable, your array is not a value type it's an identity type. However it is an array of value types thus it can be represented as a contiguous space in memory. I think they will also add value type arrays, but for those you would lose the ability to dynamically resize them, and they would be immutable, but with them you could be able to compose larger, more complex value types - I think this is where the future library work mentioned at the end would go, as this also applies to all collections.
@@sporegnosis Thank for the reply! So I still don't see the usefulness of a value class object if primitive fields are immutable. I can understand that object fields or value object fields must be immutable, but not primitive fields. If those fields are immutable that means when I create a large value array I must already have the data to initialize them already loaded into memory. That defeats the purpose of having them in the first place. It also doubles the memory required. I have always been taught to keep data in large continuous memory blocks to reduce page swapping when doing high performance computing like computational fluid dynamics (CFD) or finite element method solutions (FEM), However those calculations also require large blocks of memory to hold results, and states. I can't use immutable objects to hold results if I can't change their field values.
@@sstevenson638 It is exactly because because of the reason you state at the end of the reply. identity objects are not stored in a contiguous memory location, only their pointers are because identity objects are always stored in the heap - check the intro of the video and read about how objects are stored in the JVM. But you still misunderstand it: identity arrays will still be mutable, and with valhalla you will get the ability to create your own value objects as elements into that array that will be immutable. So if you are storing a point class in an array and wish to change it, you need to store that entire point value object again as an element, no matter how many fields it has. The feature is about performance gains, to bring the JVM closer to C and C++, and especially the work with value objects on the stack (which now supports only single primitive values) is going to be huge - it has nothing to do with new functionality per se. If you are happy with the performance of your java applications on the desktop or the cloud then this is not for you.
@@sporegnosis Is there a technical reason value objects need to be immutable or is this just a design principal? I have been looking into C# and it already has mutable value classes. My roots are in FORTRAN, C, C++, and Java. I have never used C# but I think they have made some good design decisions for folks like me interested in high performance scientific/engineering computing.
@@sstevenson638 Reasons: 1. by giving up Identity, it's just the data - there is no actual storage location logicaly, so no need to invent one or pretend that there's one. 2. you give explicit and permanent permission to the runtime to pass the value type from the heap to the stack and back, and even move it in any memory space at will, without affecting user code, or even store identical values just once like with strings. 3. it's not needed, as value types are meant for relatively small objects 4. Similar to 2 above, the value types can be passed as parameters and return values by data copy and remain consistent 4. immutability makes the object state completely atomic - as required by most of these operations and optimizations.
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.