Java Value Objects in Action with Valhalla - JEP Café #15
Ғылым және технология
How Value Objects will make it possible to write readable object oriented code with the performances of primitive based code. Get a first glimpse at what Valhalla plans to deliver in the future by following this tutorial based on the early-access build of Valhalla that you can download here : jdk.java.net/valhalla/.
⎯⎯⎯⎯⎯⎯ Chapters ⎯⎯⎯⎯⎯⎯
0:00 Intro
0:33 Introducing the Valhalla project
1:51 JEPs already delivered by Valhalla
2:45 Performance price of Object Oriented abstractions
6:26 Using value objects and primitive objects to improve performances
8:24 Introducing Value based classes and Primitive classes
9:12 Getting of identity to create value objects
12:41 Using values instead of references
13:59 Constraints on writing value based classes
14:53 Valued based types: classes, abstract classes, and interfaces
16:08 The special case of the Object class
18:27 JVM optimizations
18:52 Final words and outro
⎯⎯⎯⎯⎯⎯ Resources ⎯⎯⎯⎯⎯⎯
◦ Project Valhalla ➱ openjdk.org/projects/valhalla/
◦ Project Valhalla mailing list ➱ mail.openjdk.org/mailman/list...
◦ Project Valhalla Early Access build ➱ jdk.java.net/valhalla/
◦ Project Valhalla Early Access build notes ➱ openjdk.org/projects/valhalla...
◦ Value Objects (Preview) ➱ openjdk.org/jeps/8277163
◦ Primitive Classes (Preview) ➱ openjdk.org/jeps/401
◦ Classes for the Basic Primitives (Preview) ➱ openjdk.org/jeps/402
◦ Universal Generics (Preview) ➱ openjdk.org/jeps/8261529
◦ Nest-Based Access Control ➱ openjdk.org/jeps/181
◦ Dynamic Class-File Constants ➱ openjdk.org/jeps/309
◦ JVM Constants API ➱ openjdk.org/jeps/334
◦ Hidden Classes ➱ openjdk.org/jeps/371
◦ Warnings for Value-Based Classes ➱ openjdk.org/jeps/390
◦ Records ➱ openjdk.org/jeps/395
◦ JEP Café on Records ➱ • Records Patterns, Perf...
◦ Dev.java ➱ dev.java
◦ Inside.java ➱ inside.java
◦ JDK 19 ➱ openjdk.org/projects/jdk/19
◦ JDK 20 ➱ openjdk.org/projects/jdk/20
◦ OpenJDK ➱ openjdk.org
◦ Oracle Java ➱ www.oracle.com/java/
Tags: #Java #Java17 #Java20 #OpenJDK #JDK #JDK17 #Records #ValueTypes #ValueObjects #Valhalla #JEPCafe #insidejava
Пікірлер: 106
A lot of people keep talking about Loom and virtual threads, I personally find Project Valhalla more interesting, yet I fully agree that the mix of Loom, Valhalla, Amber, Leyden and Panama, is going to be a game changer for the Java ecosystem. Thanks for all of this!
@ambarishkapil8004
Ай бұрын
Also going to make Java a whole lot complex.But I suppose, Java was never meant for the faint hearted!
Merci José. Great job! Music settings are perfect and better than previous.👌
@31redorange08
Жыл бұрын
Better? Maybe. Perfect? Hell no.
@JosePaumard
Жыл бұрын
Thanks Khaled!
Can't wait for the second part on primitive classes!
As always - very useful and nicely presented. Thanks
Excellent as always. I think I'll have a play around with Valhalla. Looks interesting :)
Great video and explanation! Keep up the good work and give us some more :D
Thanks so much for sharing such a valuable update.After project Loom, Valhalla will make java more faster
Thanks for the video. Really helpful
Contenu très utile ! Merci beaucoup José ! Je constate que les concepteurs des certifications OCP auront de la matière pour les prochains examens 🙂
Great video!
Value Objects are exciting!!!
Cool, I will finally be able to write readable code in LeetCode :P
Interesting!💚💙💜🤍❤🧡
Thanks Jose sir.
Hello, What if I do Arrays.sum() for both arrays and then do division so any change will be seen as I am using jdks in built functions
Great video, thanks for the effort, Valhalla looks like very interesting, I need to learn first Java 17 xD
@java
Жыл бұрын
You should! PS: Thanks!
As always, great content, great video! After watching, I have two questions: 1) Could you make a tutorial (or provide a link to some articles/videos) on how to measure performance, as you do? 2) Why should we not use instance initializers in our code? Is it a performance hit or something else? Thanks in advance.
If I got correctly, value classes are inlined in case of usage if C2 compiler if they are passed as an arguments. It means that we have got overhead of copying of data . So likely this optimisation will depend on size threshold. What about passing the stack pointer then with ability to convert value object into heap object if passed reference leaks the called method ? Are such optimizations considered ?
thanks a lot!
Thank you
Very important question: where can I find that Java coffee cup? I'd love it but can't seem to find it.
Thanks for a good and comprehensive video. I have a question about the behavior of generic classes: Is there a way to mark that a generic parameter is considered a value type?
@JosePaumard
Жыл бұрын
Good idea, I haven't try it. I guess that declaring a value based interface and then T extends ValueInterface would work?
is the benchmarking code available anywhere?
Thanks a lot for this presentation. Does it means that the value objects will live in the Stack instead of the Heap?
@JosePaumard
Жыл бұрын
They can. This is for the JVM and optimizers to decide. For primitive types, they could live on the heap and in registers.
Question, what about the record class, for example? Will it allow both value and identity? It'll make sense for it to be value only. What about backwards compatibility tho?
@JosePaumard
Жыл бұрын
Record is not a value based class as of now, in this EA release. Maybe in the future?
Great job José, Question: At 8:08, Why use a primitive keyword on the record type? Couldn't the compiler infer the Product's primitive attribute types as ints?
@JonHaa87
Жыл бұрын
The main point of primitives is that they can't be null as you're not using references anymore. So even if a record only contains primitives, the compiler can't set the record automatically to primitive itself, as that would cause a huge behaviour change. For example an empty array of that record type would no longer contain nulls.
@JosePaumard
Жыл бұрын
You can. The compiler doesn't do this inference.
Jose, do you think that for graphics and game development purposes vecmath classess such as Vec2 Vec3 Mat4 etc should be defined as value classes or primitive classes?
@bororobo3805
Жыл бұрын
Well, given the stated performance features, I think it'd be better to have them as primitives.
What is the use of "value abstract class" if you can't declare fields? Aren't they effectively less useful interfaces!? What reason lies to the no field inheritance rule? I know it has to do something with the object memory layout but I don't get the reason for the restriction.
@zhamed9587
Жыл бұрын
An abstract class can have static members as well as protected methods.
Finally Java could get close to C#.
@gsit80
8 ай бұрын
I didn't know C# had value objects.
Thank you for these content How de you test it ? And do you use for test ?
@JosePaumard
Жыл бұрын
Tests and benches are done using JMH. More details -> openjdk.org/projects/code-tools/jmh/
I recall certain abstract classes and interfaces being neither identity or value unless explicitly specified; is this still the case?
@bizoitz86
Жыл бұрын
14:53
I didn’t quite get one point. With current restrictions on value abstract classes, how do they differ from value interfaces with default methods?
@roge0
8 ай бұрын
static non-final fields? idk
At 14:53 in the shown code it should identity not identiy, shouldn't it?
Jose, why not use records as value objects? If value objects and records are inmutables.
can someone pleaes explain why the two loops approach is faster than the one loop way?
@JosePaumard
Жыл бұрын
It has to do with pointer chasing. The loops version keeps switching from one array to the other, which is an overhead.
@pradimark
Жыл бұрын
Makes a lot of sense! Thanks for the explaination
@vtvitibttboybobtottbo
Жыл бұрын
After you loaded the first value from the array A, the rest of that array (or at least a part of it) goes to the CPU cache. Now if you switch to another array B, you basically will discard all that CPU cached data from the array A in order to load data from array B. So basically CPU tries to help you with performance by loading the next portion of the array that you currently reading. But as soon as CPU loads data in cache, you're just switching to another array. Now CPU needs to load data from another array to the cache. And so on. So performance is awful. This is basically the case when you do non-linear reads from the RAM. Which is always will come with hit to the performance. In order to avoid that, the most simple solution, is to make sure your program is always reading data from memory in linear and predictable way. For example, reading all data from the one array first (just doing subsequent reads from the one portion of the memory) and then switch to reading all data from another array (which is in another region of memory). You can learn about it from the this cppcon talk: kzread.info/dash/bejne/dIRqsNqPqKe3edY.html - it talks about memory access patterns and how they're important for performance.
@vtvitibttboybobtottbo
Жыл бұрын
And please don't believe me or anyone. Always trust information that you can verify. So I will recommend you to take code examples from that video (or from the talk I sent to you) and run a profiler and try to explain to yourself why it performs in a different way. There are a lot of surprises that you can find. P.S. CPU in reality doesn't have notion of arrays. It just loads in cache whatever is nearby in memory. Or tries to predict your read pattern and loads the "next data". That "next data" will not always be what you expected. But in the most cases, it is just whatever is nearby in memory towards direction of your reads.
@vtvitibttboybobtottbo
Жыл бұрын
And keep in mind that any other READ operation from any other thread or the process on the same CPU core might affect which is currently in the CPU cache. For example, In Java there is Garbage Collector running in the background which can just stop execution of your program at any given time and "pollute" the CPU cache with its data.
what's wrong with instance initilizers?
At 14:45 identity is mispelled as "identiy"
Are these benchmarks for "value record" or "primitive record" classes?
@bororobo3805
Жыл бұрын
He said primitives will be discussed next time. This discussion was about value record
@almazglaz
Жыл бұрын
@@bororobo3805 Indeed it was said. Though I when I run the very same demonstrated benchmarks I get very different numbers, hence the question.
What's that error number in the benchmarks?
@31redorange08
Жыл бұрын
Probably "standard error", a statistical metric. This has nothing to do with logical errors.
@JosePaumard
Жыл бұрын
Yes. That's exactly that. More details -> openjdk.org/projects/code-tools/jmh/
I always wondered if a *primitive value record can have String fields*? Doesn't matter if there would be a new primitive String class.
@JosePaumard
Жыл бұрын
The problem is that String wraps an array that is not limited in size. So it would become impossible to inline if it's too big.
@zhamed9587
Жыл бұрын
@@JosePaumard I'm a bit confused. Why does it prevent inlining since String itself is a reference, and would take up a one word field in the record?
Is this just allocating on the stack, which is a feature that Java should've had from the beginning?
@corinnarust
Жыл бұрын
primitive classes in this case, I don't think so about value classes also, if you put primitive types (even the primitive primitives like boolean, int) in a class field, you are always allocating
The ultimate Java evolution. WTF.
if java could be a human it would be this guy
Yeah, great stuff. On the other hand C# has had value types since the very beginning.
Why doesn't valhalla provide a mutable equivalent to primitive classes? I can understand why value classes are immutable, but I can see many cases where mutable non-reference/primitive classes could be useful. And it wouldn't cause the same problems as mutable value classes because there is only one reference to that object at any time because they're always implicitly copied
I laughed when he said never to use instance initializers, I didn't think they were that bad
value object(value record) get better performance than reference objects(identity record) 1. value objects are non modifiable 2. can't use synchronization
The new "value" keyword might break a lot of codes, I hope it ends up like var reserved keyword
I would like more btw if you do not pause/skip the java sip :) it is strange that you are almost going to drink the coffee then a little blink and you return the cup :+)) don't know :) maybe me personally will like to still have the same music but not the video gap :)
so, is record not value class? Should we say "value record" ?? 😢
I think I've found José's cafe. kzread.info/dash/bejne/f42EuLOck6vOcbQ.html
Thanks. But I would leave that cup down, and stop drinking coffee between breaks (or cut it from video)..
I don't really like this at first glance. Performance is cool, but the constraints on class construction and inheritance feel like an inconsistency in the language. Plus, I feel that between Records and Primitive classes the Value classes don't really feel necessary. If I can have primitive classes and records, what is the big benefit of value classes between the two? Records give up mutability and enforce a canonical constructor for language elegance, pattern matching, etc. Primitive classes will give up mutability and identity for a high performance, dense memory layout and probably put constraints on inheritance, like value classes do. That feels like it leaves value objects as some in-between solution that does a bit of everything, but nothing properly, is hardly needed, but makes the language more cluttered with unimportant things one needs to learn in order to understand it properly.
@andrewlalis
Жыл бұрын
I think they should have just added a C-style struct to Java and called it there. The complex constraints really limit the applicability of these new language features, when so many people are familiar with the classic struct format.
@zhamed9587
Жыл бұрын
@@andrewlalis C-style structs come with their own challenges. See what C# for example how they have structs, ref structs, readonly structs, etc. which also give you different behaviors not dissimilar from value and primitive classes.
@bobbycrosby9765
Жыл бұрын
My understanding is they have both primitive and value classes primarily for two reasons: tearing and default values. Value objects let you use null, primitive objects don't. Not every object is going to have a "sensible" default. 0 kinda makes sense for integers. But what about a Date? What is a "sensible" default? January 1st, 1970? Primitive objects also will re-introduce tearing as a problem. 64 bit values used to be able to "tear": reading and writing wasn't atomic, so a concurrent thread could see partially written primitive types. This isn't a problem on the modern JVM, but it's a tradeoff of performance here, one they weren't willing to make with primitive objects - for performance reasons, they can tear. Value objects won't have this problem, as reading and writing a reference is atomic. As far as just using C-style structs... the design of this seems particularly tailored towards opening up options for optimization. I'm not sure if they could get the same guarantees with C-style structs.
@brixomatic
Жыл бұрын
@@bobbycrosby9765 well, I can't comment on tearing, but since records are already immutable (and I expect primitives to be too), should that not eliminate tearing in the first place? And as for defaults, we have the "Optional" monad for that. It might not be perfect for parameters, but it's a better concept than null references and method overloading can avoid some of the ugly regarding optional parameters.
@bobbycrosby9765
Жыл бұрын
@@brixomatic that only works if you write your whole program as immutable. A plain old object with a primitive field will be subject to tearing - e.g. when you assign that field to a new value. Note that each primitive type will also have a value type automatically created for you. For value objects, part of the concern may have also been backwards compatibility. My understanding is they plan to migrate several existing classes to value objects. Value types are much more backwards compatible than primitive types. I'm also not sure if they're quite so willing to abandon null. Bringing this together a bit, if Optional were changed to a primitive type, then assigning it could be subject to tearing - an identity object in a multi threaded environment could be accessed in a way such that one of its Optional fields wasn't internally consistent.
and if you don't know what is an instance initializer, thats perfect. Never use that any way. 🤣🤣🤣🤣🤣🤣🤣
damn, it is really hard to understand this type of english, can u please provide somebody else? i'm not native speaker to listen this without subtitles
@adrianrostkowski2862
Жыл бұрын
I am also not a native speaker and my English is not very good. But his English is perfect and easy to understand.
@kitkarson4226
Жыл бұрын
I am not a native english speaker. I can understand just fine. His english is too good!
@brixomatic
Жыл бұрын
Not a native speaker here, but I think his English is comprehensible enough. You just need to get a bit used to it.
@romank9482
Жыл бұрын
@@brixomatic definitely disagree, intonation is really nasty, even when i'm listen to black people where their english is really too much native with swallowing a lot of words :-) i can understand them much clearly then this speaker. probably you know this accent because you are from the same country. but this english is really bad to hear.
@brixomatic
Жыл бұрын
@@romank9482 accents really are something you learn to understand and not every accent is equally hard to understand for everyone, I get that. I have a lot of Indian co-workers and it took years for me to understand some of them properly (you know, the type of calls us where you say "could you send this to me via email, so I won't forget", so you don't have to admit you understood absolutely nothing?) This accent here is a piece of cake in comparison. And also some Brits are near impossible for me to understand. Yes he's flowing some words together and his intonation is very soft, and sometimes he pronounces the last syllable instead of the first one, but that's something that you can get used to very quickly, once you understand the pattern, because that's pretty consistent.