Value Objects in Valhalla

Подписаться 179 тыс.

Просмотров 15 тыс.

50% 1

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

Наука

Опубликовано:

27 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 57

@kennytvn 10 месяцев назад

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

@user-pi9cj2or5n 10 месяцев назад

Ooo, this is being bookmarked for after work :D

@pr0master 10 месяцев назад

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

@Art-kz6zf 10 месяцев назад

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. 🍃

@stcattc 10 месяцев назад

Same thing for virtual threads...

@StefanReich 10 месяцев назад

Climate hysteria isn't real. But saving energy is of course a good thing

@Adowrath 8 месяцев назад

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..

@ndrvsk 10 месяцев назад

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")

@markandrievsky6317 10 месяцев назад

@Java what do you think about it?

@ndrvsk 10 месяцев назад

@@alexk4062 could you be more precise what exactly will be broken?

@user-pi9cj2or5n 8 месяцев назад

@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

@jay_sensz 10 месяцев назад

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

@loic.bertrand 10 месяцев назад

yes, in reality, the Optional class is implemented using a single field carying the value or null, which is more appropriate.

@ExEBoss 10 месяцев назад

The primitive‑specialised `Optional` classes `OptionalInt`, `OptionalLong`, and `OptionalDouble` use (isPresent: boolean, value: int/long/double).

@willemvanderveen7567 6 месяцев назад

Looks good!

@juliandurchholz 10 месяцев назад

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.

@juliandurchholz 10 месяцев назад

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...

@juliandurchholz 10 месяцев назад

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?

@hilligans1 10 месяцев назад

Yay Valhalla

@NachtmahrNebenan 10 месяцев назад

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

@bourne2program 10 месяцев назад

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.

@zhamed9587 10 месяцев назад

@@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.

@denis_iii 10 месяцев назад

@@zhamed9587 Two Strings cannot share a one (common) byte[] array because they (Strings) are immutable.

@FABGIO1 10 месяцев назад

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

@alessioantinoro5713 10 месяцев назад

Records are between Objects and Values

10 месяцев назад

They are indeed candidates for value types, they are implicitly final and their fields are final, equals and hash code are component based.

@diegoshevek5927 10 месяцев назад

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

10 месяцев назад

@@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

@diegoshevek5927 10 месяцев назад

@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

@LeoKingCrimson 10 месяцев назад

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

@clementcherlin 10 месяцев назад

No. I've tried to convince the Valhalla Experts Group otherwise, but haven't made much progress.

@kotlinsky. 4 месяца назад

Valhalla wen, 10 years

@sporegnosis 3 дня назад

Soon 11... by the time it comes out, we'll all be in Valhalla...

@sstevenson638 4 дня назад

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.

@sporegnosis 3 дня назад

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.

@sstevenson638 3 дня назад

@@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.

@sporegnosis 2 дня назад

@@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.

@sstevenson638 2 дня назад

@@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.

@sporegnosis 2 дня назад

@@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.

@cmyanmar13 9 месяцев назад

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.

@gsit80 8 месяцев назад

mental health.

@user-zq8bt6hv9k 10 месяцев назад

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.

@nomader5537 10 месяцев назад

ok dude

@diegoshevek5927 10 месяцев назад

No, thank you.

@jay_sensz 10 месяцев назад

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 10 месяцев назад

"oop mindset" - dude, its java its meant to be oo. If you dont like it change your language!

@user-zq8bt6hv9k 10 месяцев назад

@@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

@gsit80 8 месяцев назад

Nobody will ever use this feature.