Hi Nicolai. Small correction, hope you don't mind - G1 isn't the real default Garbage Collector (as stated in ua-cam.com/video/kzjGp7LmW0I/v-deo.html ). SerialGC might actually be chosen depending on CPU/memory available. It is not uncommon for people using containers, for instance, to have a setup on which the virtual machine has access to a low amount of resources and therefore SerialGC is picked. While that statement is somewhat close to the truth, it can be a bit misleading 🙂Cheers and thanks for all the nice work you guys do!
@@kamurashev No, he's right and I forgot about that when writing that line. There's no one default GC - the runtime will pick one based on CPU and memory. On non-ancient stand-alone machines (like dev machines), this will be G1, but on a restricted cloud instance, it may well not be.
@@Lpx288 It's not super clear, but it is covered under the ergonomics section in the GC tuning guide: docs.oracle.com/en/java/javase/22/gctuning/ergonomics.html#GUID-DA88B6A6-AF89-4423-95A6-BBCBD9FAE78, specifically the note about what the JVM considers to be a "server class machine" I mention it more specifically here: inside.java/2022/08/08/sip063/ I think there was some discussion on changing those parameters to make Serial less frequently chosen... I'll need to check with the GC team on that.
Valhalla is needed for any performance intensive processing, not just physics or engineering. I am an ex-physicist now working in information processing and I need Valhalla to reduce the number of effectively random memory lookups. I have numerous small objects that are good candidates for conversion to a value type. Being value types would avoid at least one memory access. Sometimes these are nested with the enclosing type remaining small, so two or more (random) memory accesses in that case. And I have numerous arrays and lists (of arrays) where the entries are good candidates for value types, and hash maps where the keys can be converted to value types. Valhalla will make a massive difference to almost any program with a lot of memory access or a lot of use of small types.
I agree, but keep in mind that progress isn't slow because of a lack of effort. It's slow because the situation and solution are very complex, which is further complicated by the goal to expose as little as possible of that complexity to us developers.
@@curio78 This is a huge exaggeration. Java has been used for high-performance and numerical work for a long time. The Java NAG library has been available for decades. Valhalla and universal generics aren’t showstoppers by any means. What they will allow is for very high performance numeric code to be written in a clear OOP manner that can be fully optimised by hotspot. It will make high-performance numeric code easier to write in Java than in Fortran or C/C++. Java can take its rightful place as the language that scientists and engineers and statisticians should be using to write apps and libraries. It could revolutionise the way numeric code is written and maintained.
Thanks guys! This is super awesome. We, the educators, asked and you listened. With the new modifications to the implicitly declared classes and the automatic imports of java.util, java.math and most importantly of the extremely handy static methods in the new IO class, it's time to revert to teaching introductory programming courses with our beloved Java.
String templates removal is truly disappointing. A feature that is such a quality of life improvement and that is present in almost every popular language for at least a decade. Sad.
Hi there. Is there some news on the Vector Api? When they will exit the incubation state? I put a lot of effort to use them in my program and they are devastating on some loads with CPUs that supports AVX512. My concern is that I'll need to rewrite everything for API changes when the APIs will exit the incubator state. I have some "development questions" on those APIs, are there a mailing list where to discuss about the use and the benefit of those APIs?
If you want to advance in Java from basic to intermediate and advanced subjects, what are the best courses that exist at a reasonable price? Do you have any recommendations?
Hello. One feature of the new way statements can appear before a call to super in a constructor that seems a bit worrying to me is the assignment of fields. A great thing seems to be the capacity to validate parameters and do other checking in calls to constructors before calling super and hence before memory is allocated to the object being constructed. If one can set fields in a call before super, will this interfere with how this seems?
Perhaps I taking to myself, but still, perhaps assigning fields is fine because they will be made available to a presumptive "this" only after the call to super. I think allowing statements before a call to super has a potential to be a very good thing for Java.
I am really not looking forward to the memory access removal. Maybe I'm lacking some knowledge here but for example. Here is a very simple library. There is a class called FormatToString that simply takes an annotation from the class and converts it in to a toString function. Eg: "Foo{bar: #bar}" Now the user clearly intends the bar field/accessor to be used but it may not want to publicly expose as it may just be something related to string display. Without the memory access that contract can no longer be fulfilled and the user must manually allow the library to access things via reflection what defeats the purpose of something that is supposed to make things simpler and faster to write.
Using memory access to read fields can break on any minor Java update, on other JVMs, even when everything else stays the same, it could theoretically break non-deterministically when some run-time optimization lays out fields differently. This is a terrible use of that capability and that any random dependency of a dependency of a dependency can silently break an app's integrity like that is kinda bonkers. So it's good that it goes away. If the library used bytecode generation or reflection instead, users can unlock the capability with a simple command line flag and thus acknowledge that they accept the compatibility risk.
I mean I'm for removing unsafe when there is a suitable alternative (with the edge case of tight performance requirements) For example, the byte[] primitive access by offsets has a var handle alternative and it is really good. But for things such as fields, obtaining a var handle can be a large pain or just impossible without unusual permissions. I'm all for unsafe removal if it can be replaced. Currently and sadly, that is not the case and while it is much better than it used to be, it's not quite there yet.
@@lapissea1190 You missed (or at least didn't reply to) the central part of the rationale: It doesn't matter how useful it is, *nothing* should be able to undermine an application's integrity unless the people running it give explicit permission.
Oh apologies! Yes but it's also more than unsafe? It might just be my forte in to 3d graphics but almost all causes of crashes in my experience are not related to unsafe but loading of external code. Something that is very much allowed and requires no explicit permissions.
If at least something would be available for string templating in Java, say, like compact() in PHP laravel. Though, with String.format(), I can achieve enough which I want. but it could be probably simplified with the approach like compact(). Probably it could be achieved when project Babylon will stand and jump.
Hi Nicolai. Is OpenJDK and JDK have the exact same features and source codes ? Who determines what new features will be added, what old features will be fixed, and what old features will be removed (deprecated) in newer versions of the JDK, is it the community or the internal Java team at Oracle ?
String templating always seemed to be a strange addition to Java. One of Java’s great strengths is compile-time checking and code analysis, which is broken by string templating. Templating also adds new syntax to be handled by transpilers. I hope it isn’t added back. Its function can be replaced by combinations of string formatting and lambdas. Keep functionality and variable names as pure Java!
I always find myself trying to use them for something more than a string template, and always get reminded about inherently String-bound nature of TemplateProcessors.
wake me up when valhalla it will be here, 10 years is too long, the development is too slow, and java have lost a lot of ground compared to the other language
For real. Valhalla would be such a game changer but I feel like they're taking way too long. Yes I get that it's a nontrivial task, but they've been working on it since 2014! That's 10 whole years! More than enough time to rewrite the entire JVM itself. 😮
They figured out that they don’t need special syntax to achieve the optimizations they wanted. New syntax should always be avoided if at all possible to reduce bloat in the language. Since they can achieve the same performance without it, they need to completely redesign the api for that feature. It will be back, they just removed it since it makes no sense to keep it as preview knowing it will be changed completely
Lol, he’s so excited about the new JDK 23 when Java is already irrelevant in the world. You should be thinking not about the 1% of people who use the new version, but about those who can’t afford to use the new features in the older versions of the language. Enterprise is stuck on version 8 and can’t afford to use your innovations. Nobody starts new projects in Java anymore; everyone is using more reliable and modern languages like Golang for backend or Rust. When enterprise wants to get rid of legacy, they choose Golang over Java, and there are dozens of such examples. Someone please tell Oracle and the author of the video that it’s not the year 2000, good morning. Nobody needs their dinosaur with tons of junk inside that they can never get rid of. Just keep making your JVM, the only thing that can be useful. No project Valhalla or any other will save this language from falling into the abyss; Cobol will have a neighbor at the bottom. New logo for Oracle -> 🤡 (clown)
This 'stuck on Java 8' thing isn't as relevant anymore. I have been using Java 21 on a daily basis since November. If you look at the 'show of hands' the presenters are doing at conferences, fewer and fewer are still on Java 8.
Say "gatherer" 3 times in a row and you will understand why it is such a poor name. A more concise, and intuitive name like "pipe" would be much more fitting, imho. Stream.of(1, 2, 3).pipe(🍄=> collect(🍄)).toList();
Hi Nicolai. Small correction, hope you don't mind - G1 isn't the real default Garbage Collector (as stated in ua-cam.com/video/kzjGp7LmW0I/v-deo.html ). SerialGC might actually be chosen depending on CPU/memory available. It is not uncommon for people using containers, for instance, to have a setup on which the virtual machine has access to a low amount of resources and therefore SerialGC is picked. While that statement is somewhat close to the truth, it can be a bit misleading 🙂Cheers and thanks for all the nice work you guys do!
Default means default. If you do not provide/choose any overrides it would go with g1.
@@kamurashev No, he's right and I forgot about that when writing that line. There's no one default GC - the runtime will pick one based on CPU and memory. On non-ancient stand-alone machines (like dev machines), this will be G1, but on a restricted cloud instance, it may well not be.
I was looking for this info the other day but didn't find any documentation. Do you have any link by any chance? Ty
@@nipafx what is the case it will choose ZGC as the default one?
@@Lpx288 It's not super clear, but it is covered under the ergonomics section in the GC tuning guide: docs.oracle.com/en/java/javase/22/gctuning/ergonomics.html#GUID-DA88B6A6-AF89-4423-95A6-BBCBD9FAE78, specifically the note about what the JVM considers to be a "server class machine"
I mention it more specifically here: inside.java/2022/08/08/sip063/
I think there was some discussion on changing those parameters to make Serial less frequently chosen... I'll need to check with the GC team on that.
Valhalla and vector api are really needed for physics and engineering computing. I know we are a small market but please! Finish them already!
I agree!
Valhalla is needed for any performance intensive processing, not just physics or engineering. I am an ex-physicist now working in information processing and I need Valhalla to reduce the number of effectively random memory lookups. I have numerous small objects that are good candidates for conversion to a value type. Being value types would avoid at least one memory access. Sometimes these are nested with the enclosing type remaining small, so two or more (random) memory accesses in that case. And I have numerous arrays and lists (of arrays) where the entries are good candidates for value types, and hash maps where the keys can be converted to value types. Valhalla will make a massive difference to almost any program with a lot of memory access or a lot of use of small types.
@@curio78 It’s the way I used to program Fortran in the 80s.
I agree, but keep in mind that progress isn't slow because of a lack of effort. It's slow because the situation and solution are very complex, which is further complicated by the goal to expose as little as possible of that complexity to us developers.
@@curio78 This is a huge exaggeration. Java has been used for high-performance and numerical work for a long time. The Java NAG library has been available for decades. Valhalla and universal generics aren’t showstoppers by any means. What they will allow is for very high performance numeric code to be written in a clear OOP manner that can be fully optimised by hotspot. It will make high-performance numeric code easier to write in Java than in Fortran or C/C++. Java can take its rightful place as the language that scientists and engineers and statisticians should be using to write apps and libraries. It could revolutionise the way numeric code is written and maintained.
Another excellent (informative) video thank you Nicolai
Thank you! 💙🧡
Thanks guys! This is super awesome. We, the educators, asked and you listened. With the new modifications to the implicitly declared classes and the automatic imports of java.util, java.math and most importantly of the extremely handy static methods in the new IO class, it's time to revert to teaching introductory programming courses with our beloved Java.
The best informative newscast about java
THIS ALL IS AWESOME EXCEPT FOR THE STRING TEMPLATE PART!!!
String templates removal is truly disappointing. A feature that is such a quality of life improvement and that is present in almost every popular language for at least a decade. Sad.
It's not gonna be removed forever, they just need more time to change how they are implemented into the language
@@Kroppebyep. It’s only going to take 5-10 more years, no big deal
Yeah, I'm looking forward to Nicolai's video explaining why it was removed.
Kotlin rulez baby!!!
@@IfeSunmola which part of the reasoning made sense? 🤔
Excellent video, THX!
Hi there. Is there some news on the Vector Api? When they will exit the incubation state? I put a lot of effort to use them in my program and they are devastating on some loads with CPUs that supports AVX512. My concern is that I'll need to rewrite everything for API changes when the APIs will exit the incubator state. I have some "development questions" on those APIs, are there a mailing list where to discuss about the use and the benefit of those APIs?
😂 6:08 no pressure Brian, but WHEN WILL IT COME?
Why String templates jep has been dropped?
What about a nulls native support, like in C# and Kotlin. ?.
Omg it’s so disappointing those string templates. We need this thing
It is not really disappointing, it will most likely come back. I want a properly designed feature instead.
@@squidxtv I need it yesterday or the day before that
@@squidxtvYes but when… JDK 30😢?
I think the "STR" prefix on string template were to much bloat. I rather see a redesign.
@@DinMamma002 yeah exactly, imo it's not necessary to reinvent the wheel with this. Just look at other languages, how they approach this.
If you want to advance in Java from basic to intermediate and advanced subjects, what are the best courses that exist at a reasonable price? Do you have any recommendations?
Thanks 🎉
You gotta believe in Valhalla with Me
I do!
I do!!
Would it be possible if anyone did the work to backport the Markdown Javadocs to JDK21?
Thanks
Hello. One feature of the new way statements can appear before a call to super in a constructor that seems a bit worrying to me is the assignment of fields.
A great thing seems to be the capacity to validate parameters and do other checking in calls to constructors before calling super and hence before memory is allocated to the object being constructed. If one can set fields in a call before super, will this interfere with how this seems?
Perhaps I taking to myself, but still, perhaps assigning fields is fine because they will be made available to a presumptive "this" only after the call to super.
I think allowing statements before a call to super has a potential to be a very good thing for Java.
I am really not looking forward to the memory access removal. Maybe I'm lacking some knowledge here but for example. Here is a very simple library. There is a class called FormatToString that simply takes an annotation from the class and converts it in to a toString function. Eg: "Foo{bar: #bar}" Now the user clearly intends the bar field/accessor to be used but it may not want to publicly expose as it may just be something related to string display. Without the memory access that contract can no longer be fulfilled and the user must manually allow the library to access things via reflection what defeats the purpose of something that is supposed to make things simpler and faster to write.
Using memory access to read fields can break on any minor Java update, on other JVMs, even when everything else stays the same, it could theoretically break non-deterministically when some run-time optimization lays out fields differently. This is a terrible use of that capability and that any random dependency of a dependency of a dependency can silently break an app's integrity like that is kinda bonkers. So it's good that it goes away.
If the library used bytecode generation or reflection instead, users can unlock the capability with a simple command line flag and thus acknowledge that they accept the compatibility risk.
I mean I'm for removing unsafe when there is a suitable alternative (with the edge case of tight performance requirements)
For example, the byte[] primitive access by offsets has a var handle alternative and it is really good. But for things such as fields, obtaining a var handle can be a large pain or just impossible without unusual permissions. I'm all for unsafe removal if it can be replaced. Currently and sadly, that is not the case and while it is much better than it used to be, it's not quite there yet.
@@lapissea1190 You missed (or at least didn't reply to) the central part of the rationale: It doesn't matter how useful it is, *nothing* should be able to undermine an application's integrity unless the people running it give explicit permission.
Oh apologies! Yes but it's also more than unsafe? It might just be my forte in to 3d graphics but almost all causes of crashes in my experience are not related to unsafe but loading of external code. Something that is very much allowed and requires no explicit permissions.
If at least something would be available for string templating in Java, say, like compact() in PHP laravel.
Though, with String.format(), I can achieve enough which I want. but it could be probably simplified with the approach like compact(). Probably it could be achieved when project Babylon will stand and jump.
3:15 so import module is basically using namespace from c++... I'm not sure I like it.
Hi Nicolai.
Is OpenJDK and JDK have the exact same features and source codes ? Who determines what new features will be added, what old features will be fixed, and what old features will be removed (deprecated) in newer versions of the JDK, is it the community or the internal Java team at Oracle ?
OpenJDK is "the JDK". This is where Java is developed.
OpenJDK is the place Java developed, vendors can add features and release build of OpenJDK.
@@Anbu_Sampath Vendor = Oracle ?
@@PeterAdiSaputro Oracle, Redhat, Amazon, Microsoft etc.
👍
String templating always seemed to be a strange addition to Java. One of Java’s great strengths is compile-time checking and code analysis, which is broken by string templating. Templating also adds new syntax to be handled by transpilers. I hope it isn’t added back. Its function can be replaced by combinations of string formatting and lambdas. Keep functionality and variable names as pure Java!
I always find myself trying to use them for something more than a string template, and always get reminded about inherently String-bound nature of TemplateProcessors.
String formatting is compile-time checked?
@@31redorange08 No, but the use of variables and expressions as parameter for the formatting is.
Valhalla’s progress toooooo slow。
wake me up when valhalla it will be here, 10 years is too long, the development is too slow, and java have lost a lot of ground compared to the other language
For real. Valhalla would be such a game changer but I feel like they're taking way too long. Yes I get that it's a nontrivial task, but they've been working on it since 2014! That's 10 whole years! More than enough time to rewrite the entire JVM itself. 😮
5:52 - like ir. Valhalla - every avoids except Java Developer.
String Template removal has come as shock to me being honest
Yeah, I am not expecting it
Once again, we can only dream of String interpolation from other languages
it's temporary, they will come back with a finer and better syntax
The decision to remove string templates has been extremely misguided, very very sad. I still don't understand the justification.
They figured out that they don’t need special syntax to achieve the optimizations they wanted. New syntax should always be avoided if at all possible to reduce bloat in the language. Since they can achieve the same performance without it, they need to completely redesign the api for that feature. It will be back, they just removed it since it makes no sense to keep it as preview knowing it will be changed completely
Give us Valhalla already wtf is wrong with you.
chill, man! 😂 don't you know how hard it is to bring such a feature?
@@lucaguadagnini8512 No I don't
@@lucaguadagnini8512 I mean they've been working on it for more than 10 years wtf. C# has value type from day 1
It's been 10 years. How hard can a task be? @@lucaguadagnini8512
Even Einstein's theory of relativity took him less time than Project Valhalla is taking right now. 😅
Lol, he’s so excited about the new JDK 23 when Java is already irrelevant in the world. You should be thinking not about the 1% of people who use the new version, but about those who can’t afford to use the new features in the older versions of the language. Enterprise is stuck on version 8 and can’t afford to use your innovations. Nobody starts new projects in Java anymore; everyone is using more reliable and modern languages like Golang for backend or Rust. When enterprise wants to get rid of legacy, they choose Golang over Java, and there are dozens of such examples. Someone please tell Oracle and the author of the video that it’s not the year 2000, good morning. Nobody needs their dinosaur with tons of junk inside that they can never get rid of. Just keep making your JVM, the only thing that can be useful. No project Valhalla or any other will save this language from falling into the abyss; Cobol will have a neighbor at the bottom.
New logo for Oracle -> 🤡 (clown)
I use java, it's been a year now and it's great🙃
You cared so much that you had to comment. It means probably java is opposite to what you say.
@@JoeMwangi😂 good response
This 'stuck on Java 8' thing isn't as relevant anymore. I have been using Java 21 on a daily basis since November.
If you look at the 'show of hands' the presenters are doing at conferences, fewer and fewer are still on Java 8.
Bro is clearly a go fan boy but he's on every java video lmao
Say "gatherer" 3 times in a row and you will understand why it is such a poor name. A more concise, and intuitive name like "pipe" would be much more fitting, imho.
Stream.of(1, 2, 3).pipe(🍄=> collect(🍄)).toList();
Lol I like the Choice of variable name 😂