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
3 ай бұрын
Also going to make Java a whole lot complex.But I suppose, Java was never meant for the faint hearted!
@pablourbanohernandezvizcarra
Жыл бұрын
Great video, thanks for the effort, Valhalla looks like very interesting, I need to learn first Java 17 xD
@java
Жыл бұрын
You should! PS: Thanks!
@officialraylong
Жыл бұрын
Value Objects are exciting!!!
@Talaria.School
Жыл бұрын
Merci José. Great job! Music settings are perfect and better than previous.👌
@31redorange08
Жыл бұрын
Better? Maybe. Perfect? Hell no.
@JosePaumard
Жыл бұрын
Thanks Khaled!
@svalyavasvalyava9867
Жыл бұрын
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.
@Wovi10
Жыл бұрын
Very important question: where can I find that Java coffee cup? I'd love it but can't seem to find it.
@kostiapereguda
Жыл бұрын
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
10 ай бұрын
static non-final fields? idk
@cobrab1978
3 ай бұрын
Jose, why not use records as value objects? If value objects and records are inmutables.
@aharonha
Жыл бұрын
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?
@Markus_included
4 ай бұрын
At 14:45 identity is mispelled as "identiy"
@bizoitz86
Жыл бұрын
I recall certain abstract classes and interfaces being neither identity or value unless explicitly specified; is this still the case?
@bizoitz86
Жыл бұрын
14:53
@gsit80
10 ай бұрын
The ultimate Java evolution. WTF.
@kitkarson4226
Жыл бұрын
Thanks Jose sir.
@alexandre8869
Жыл бұрын
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.
@danielgolan
Жыл бұрын
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?
@StephenBuergler
Жыл бұрын
what's wrong with instance initilizers?
@danhoward7697
Жыл бұрын
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/
@kitkarson4226
Жыл бұрын
so, is record not value class? Should we say "value record" ?? 😢
@tarearnaut3502
Жыл бұрын
if java could be a human it would be this guy
@jNayden
Жыл бұрын
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 :)
@edmaphis9805
Жыл бұрын
I think I've found José's cafe. kzitem.info/news/bejne/ro-GvIWZnHqZdIY
@deltashit
Жыл бұрын
At 14:53 in the shown code it should identity not identiy, shouldn't it?
@yerlibilgin2
Жыл бұрын
Thanks. But I would leave that cup down, and stop drinking coffee between breaks (or cut it from video)..
@brixomatic
Жыл бұрын
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.
@prdoyle
Жыл бұрын
Can't wait for the second part on primitive classes!
@IllidanS4
Жыл бұрын
Finally Java could get close to C#.
@gsit80
10 ай бұрын
I didn't know C# had value objects.
@hosseinmahdavipur7203
Жыл бұрын
is the benchmarking code available anywhere?
@MykolaPavluchynskyi
Жыл бұрын
As always - very useful and nicely presented. Thanks
@redcrafterlppa303
Жыл бұрын
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.
@engineersunit
Жыл бұрын
Thanks for the video. Really helpful
@Markus_included
4 ай бұрын
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
@munawarabbas1636
Жыл бұрын
Thanks so much for sharing such a valuable update.After project Loom, Valhalla will make java more faster
@KangoV
Жыл бұрын
Excellent as always. I think I'll have a play around with Valhalla. Looks interesting :)
@davidhsv2
Жыл бұрын
Cool, I will finally be able to write readable code in LeetCode :P
@techtech7756
Жыл бұрын
Contenu très utile ! Merci beaucoup José ! Je constate que les concepteurs des certifications OCP auront de la matière pour les prochains examens 🙂
@andy_lamax
Жыл бұрын
and if you don't know what is an instance initializer, thats perfect. Never use that any way. 🤣🤣🤣🤣🤣🤣🤣
@VuLinhAssassin
Жыл бұрын
The new "value" keyword might break a lot of codes, I hope it ends up like var reserved keyword
@pradimark
Жыл бұрын
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: kzitem.info/news/bejne/o4ZstKyMsXaCfKg - 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.
@_whywhathow
Жыл бұрын
value object(value record) get better performance than reference objects(identity record) 1. value objects are non modifiable 2. can't use synchronization
@AndreyLomakin
Жыл бұрын
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 ?
@mihirsawant8817
Жыл бұрын
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
@ChrisBrown-dn3tf
Жыл бұрын
I laughed when he said never to use instance initializers, I didn't think they were that bad
@AleksandarT10
Жыл бұрын
Great video and explanation! Keep up the good work and give us some more :D
@VisruthCV
Жыл бұрын
Interesting!💚💙💜🤍❤🧡
@nv-systems
Жыл бұрын
Great video!
@arnaudclaudel9774
Жыл бұрын
thanks a lot!
@xKeray
Жыл бұрын
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.
@victorpinasarnault9135
Жыл бұрын
Thank you
@carldea
Жыл бұрын
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.
@mathieuS276
Жыл бұрын
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/
@NachtmahrNebenan
Жыл бұрын
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?
@almazglaz
Жыл бұрын
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.
@IndellableHatesHandles
Жыл бұрын
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
@Valder1989
Жыл бұрын
Yeah, great stuff. On the other hand C# has had value types since the very beginning.
@romank9482
Жыл бұрын
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.
Пікірлер: 106