FWIW the Generational Hypothesis does not need to be true in order for generational GC to be useful. Modern (like from the last 15 years) nurseries make very short-lived objects perform on par with stack allocation, making high-quality time-consuming escape analysis much less important.
Already done, though I don't really go into comparative footprint, throughput statistics; th-cam.com/video/IluRn8ecuCo/w-d-xo.html, if you are on mobile, select the "performance" chapter.
tri-state booleans with null can be very sensible. for example to represent a cached value. "Is this fact about my user true?" yes (cached from recent request), no (cached from recent request), or the cache returns a null to tell you to go get it from the slower access primary source
That is unclear design upfront. You are being implicit about the meaning of null, since there is no agreed upon meaning for null. I would have used optional with and IfPresentorElse() call. Or better yet, use an either monadic pattern ❤
@@vinterskugge907 That is a heyting algebra and not boolean algebra. I would use an enum instead as I already said and then add functions on top to represent the business concepts here. You need to come with a more real use case for what "i don't know" represents and what it implies in the domain. Is it a failure condition, is it used for flow control? What is it ? None of that is clear from just having three values. As all good mathematicians know, any three element sets are equivalent as sets. If you need more you need to specify it.
Just saying, removing Unsafe without real replacements is not the way to go, I think giving Users access to native methods for things like theUnsafe (jdk internal Unsafe), with things like an unsafe scope like in Rust, would be way better. Since every API exposed in the newest Version of Java is Type Safe with many checks etc. will mean an reduction in features and performance, thus we will see libraries pushing bytecode at and before runtime, what I think is much more dangerous, than giving access to all of these native methods and also makes it much harder to debug, when something goes south. Kind regards, Jakob
I also dislike that we have to explicitely allow native access to specific modules. I want my application to do what it should do, not fearing to forget some command line argument.
@@peacemakerle If you want your app to do what it should, you don't want arbitrary code from a third-level dependency be able to rewrite your entire program. Integrity by default, and `--enable-native-access` is part of that, guarantees that - details: th-cam.com/video/ucdzGd-f8as/w-d-xo.html
It's not. I know of one Norwegian company that upgrades Java in production every 6 months. There are likely others too. That's quite rare, though, but many of us are on Java 21. So could be worse.
@@VuLinhAssassin I know what you mean, but just for the record: There are no "LTS versions", there are only "versions with LTS" - details: th-cam.com/video/3bfR22iv8Pc/w-d-xo.html
Before thinking about better things I think it's important to fix what's currently broken. AWT and Swing uses 25 years old APIs and most of the features are now broken on modern OSes.
One problem of try with resources, is that it does not cover the usecase where you're preparing resources to be used at a different place and time in the code. An example would be preloading the End of level cutscene in a videogame while a player is playing a level, then executing it based on the player reaching the end of level trigger, to avoid unneeded load screens.
One technique is to have try-wr wrap your event loop, and construct a resource manager. You can then have it do preloading at any point you like, and when the event loop terminates, it's all cleaned up. So something like: void main() { try (ResMgr mgr = new ResMgr()) { eventLoop(mgr); } } void eventLoop(ResMgr mgr) { // game game game mgr.preload(cutscene()); // game game game } class ResMgr implements AutoCloseable { void preload(Cutscene cutscene) { ... } void close() { freePreloaded(); } }
There's kind of a "real problem" in that providing feed-back to these people is virtually impossible. I'm 49 years old, and started programming Java when it came out in 1997 at M.I.T. I did leave it, but I've been doing it everyday for a decade now, but I don't know who to contact (or how) to have a conversation about it.
at the very least, openjdk mailing lists do work - im subbed to them and i see sometimes people sending their messages there, leading to openjdk devs answering
I've reported a few compiler crashes through the Java Bug Database; that page has details on how to submit issues for bugs and small feature requests. They also have guidance on how to requests for larger features with the OpenJDK project and Java Community Process. It's also worth checking out the Java mailing lists.
The best would be through the dev lists: mail.openjdk.org/mailman/listinfo Of course we do monitor other locations like here, r/java, and other social media outlets. I wish I could find the video, but I remember Mark Reinhold (Chief Java Architect) gave a great answer on providing feedback. And in short, there is an importance of building relationships. Going to the dev lists and posting your vehement disagreement with for example unnamed variables ("_"), I'm not saying it will be ignored, but the threshold for which that feedback would be acted upon will be very high. Imagine a new developer coming into your organization, and their first action is giving an explanation as to why something is wrong, or how something should be done differently. The threshold on which you'd act on that feedback would probably be high, certainly if the feedback is unassailably "correct" you'll no doubt act upon it, but chances are there are reasons why a system looks the way it looks, or why processes the way they are. The reasoning for that might become clearer if that developer had spent time fixing bugs, adding new features, or doing updates, to the system, which might also then help not only in providing feedback, but also how that feedback would be received. There is also this answer from Brian Goetz that somewhat touches on feedback as well: th-cam.com/video/JehEnHGqOTY/w-d-xo.html
Generally speaking, the mailing lists are the way to go for feedback: mail.openjdk.org/mailman/listinfo Feedback is most valuable when it comes from practical experimentation with a preview features - for such cases, the specific mailing list is mentioned in the respective JEP.
implicit import of java.base is absurd... makes new people to learn Java even harder.. why sometimes you need it and sometimes you dont.... no one cares about demos guys.. java is not for demos... please remove this meaningless features that add complexity.
@@waterdudedev nope in fact trying to help the learning process. By trying to do something more simple for a demo, is not making it more simple for learning, because then you have to explain the differences and when and what and module imports and everything and bam - complexity 101
If you're a teacher working with students and want to teach them how to work with Lists or Maps, not having to handle where to import those classes from, or even imports at all, can help keeping the focus of working with data structures and not going down unrelated topics like imports. It's particularly helpful in a learning setting because, al most by definition, the students will not yet be familiar with the package structure of the JDK or how to use their IDE to look up.resolve imports. Certainly IDEs are much more powerful now, but I remember struggling with that while I was in school some years ago now learning Java.
@@billykorando its far better if this is only in jshell since i will probably use it to show structures or streams (io) or nio or etc but in a java file to somehow have auto modules imported but the moment you add a class they are not and why is that and why this module is imported but the other is not and why the hell we also have packages and real modules like module-info … its getting more compex not streamlined
Averages are nonsense, Gil covered that extensively for years now. Stop using average pause time especially in context of GC of all things... average will completely hide a massive highest pause time. ZGC is actually awesome though.
@@krellin perhaps, as Nicolai eludes to it would depend upon use case. For applications that will be interacting with human users, yea max pause times are a very important consideration. For a batch application, average pause time might be more relevant, within certain constraints. It’s been awhile since I have seen the presentation you mention, but I doubt Gil was suggesting “ignore average pause entirely”, but rather don’t over focus on it as it can be (very) misleading.
@@billykorando oh yes he was, and he demonstrated how average can tell you things are improving while they don't... very recently i saw it for myself on a real system...
basically only actually useful thing for me was better switch statements still 0 reason to go back to java from kotlin FFM is nice too but needs testing to see if they are actually doing it faster...
Preach, Kotlin is just so much better... after working with it for a couple of years it just feels so much better than Java in every way possible. Kotlin MP especially has been a game changer for my productivity
@@krellin The Java language had a pretty slow period for a decade or so between about 2005 to 2015 which left room for Kotlin. They've now changed how they manage Java, and advancements are coming quicker. Java is adopting many of the best parts of Kotlin and other languages. But Java is not the place for bleeding-edge language innovation, so if that's what you're looking for, you're probably better off with a different language. Personally, I like that they're taking their time and learning from other languages.
@@prdoyle they started innovating only because jetbrain started becoming a threat... we would still be sitting at java 8 probably. Also no i do not think they are close to adopting good practices. One of the most infuriating changes was their stupid java record classes... which for some reason have to be immutable... where in the world did someone define an immutable pojo? this is for message passing protocols, even there you dont really carea bout immutability. Kotlin is all about giving you options, and you picking what makes sense, but they insist on shoving their bias into language. Immutability is wasteful, terrible for performance and forces all the useful data to get out of cpu caches... and becuase most poeple are incompetent they will use java records as easier way to define pojos (data classes for kt)... now i have to deal with bunch of stupid issues that this brings. Most of the features they are doing imo are in meh category... i dont think markdown is considered innovation... instead of this bs they could go and revamp many poor choices they did in java NIO riddled with stupid locks and synchronizations...
Thank you so much for the content. I would like to see string templates come back in the future!
Awesome talk. Thank you so much! 😊
Great presentation🎉🎉🎉 Thanks for publishing.
Thank you! 😊
implicit import module java.base with JEP 477 is going to be amazing for experimentation
Thanks for the video
FWIW the Generational Hypothesis does not need to be true in order for generational GC to be useful. Modern (like from the last 15 years) nurseries make very short-lived objects perform on par with stack allocation, making high-quality time-consuming escape analysis much less important.
I'm more curious about the runtime optimizations side of things will there be video on that?
Already done, though I don't really go into comparative footprint, throughput statistics; th-cam.com/video/IluRn8ecuCo/w-d-xo.html, if you are on mobile, select the "performance" chapter.
tri-state booleans with null can be very sensible. for example to represent a cached value. "Is this fact about my user true?" yes (cached from recent request), no (cached from recent request), or the cache returns a null to tell you to go get it from the slower access primary source
That is unclear design upfront. You are being implicit about the meaning of null, since there is no agreed upon meaning for null. I would have used optional with and IfPresentorElse() call. Or better yet, use an either monadic pattern ❤
@@Mig440Isn't it quite clear though? A value of a tri-state boolean means either "yes", "no", or "I don't know".
@@vinterskugge907 That is a heyting algebra and not boolean algebra.
I would use an enum instead as I already said and then add functions on top to represent the business concepts here. You need to come with a more real use case for what "i don't know" represents and what it implies in the domain. Is it a failure condition, is it used for flow control? What is it ? None of that is clear from just having three values. As all good mathematicians know, any three element sets are equivalent as sets. If you need more you need to specify it.
@@vinterskugge907 No, it means "yes", "no", "I don't know", "I made a mistake", "my colleague made a mistake", or "my dependency made a mistake". 😉
Just saying, removing Unsafe without real replacements is not the way to go, I think giving Users access to native methods for things like theUnsafe (jdk internal Unsafe), with things like an unsafe scope like in Rust, would be way better. Since every API exposed in the newest Version of Java is Type Safe with many checks etc. will mean an reduction in features and performance, thus we will see libraries pushing bytecode at and before runtime, what I think is much more dangerous, than giving access to all of these native methods and also makes it much harder to debug, when something goes south.
Kind regards,
Jakob
I also dislike that we have to explicitely allow native access to specific modules. I want my application to do what it should do, not fearing to forget some command line argument.
@@peacemakerle If you want your app to do what it should, you don't want arbitrary code from a third-level dependency be able to rewrite your entire program. Integrity by default, and `--enable-native-access` is part of that, guarantees that - details: th-cam.com/video/ucdzGd-f8as/w-d-xo.html
Is my team the only one in the world using jdk 22 in production?😂
It's not. I know of one Norwegian company that upgrades Java in production every 6 months. There are likely others too.
That's quite rare, though, but many of us are on Java 21. So could be worse.
Many companies only use the LTS versions.
I hope it's 23 now (or at least very soon). 😉
We use LTS versions
@@VuLinhAssassin I know what you mean, but just for the record: There are no "LTS versions", there are only "versions with LTS" - details: th-cam.com/video/3bfR22iv8Pc/w-d-xo.html
Before thinking about better things I think it's important to fix what's currently broken. AWT and Swing uses 25 years old APIs and most of the features are now broken on modern OSes.
One problem of try with resources, is that it does not cover the usecase where you're preparing resources to be used at a different place and time in the code. An example would be preloading the End of level cutscene in a videogame while a player is playing a level, then executing it based on the player reaching the end of level trigger, to avoid unneeded load screens.
One technique is to have try-wr wrap your event loop, and construct a resource manager. You can then have it do preloading at any point you like, and when the event loop terminates, it's all cleaned up. So something like:
void main() {
try (ResMgr mgr = new ResMgr()) {
eventLoop(mgr);
}
}
void eventLoop(ResMgr mgr) {
// game game game
mgr.preload(cutscene());
// game game game
}
class ResMgr implements AutoCloseable {
void preload(Cutscene cutscene) { ... }
void close() { freePreloaded(); }
}
Bring the low memory usage, I hope lilliput+leyden+valhalla can reduce java memory usage by ~50%
mega)
I am here stuck with Kotlin, a language full of bs
There's kind of a "real problem" in that providing feed-back to these people is virtually impossible. I'm 49 years old, and started programming Java when it came out in 1997 at M.I.T. I did leave it, but I've been doing it everyday for a decade now, but I don't know who to contact (or how) to have a conversation about it.
at the very least, openjdk mailing lists do work - im subbed to them and i see sometimes people sending their messages there, leading to openjdk devs answering
I've reported a few compiler crashes through the Java Bug Database; that page has details on how to submit issues for bugs and small feature requests. They also have guidance on how to requests for larger features with the OpenJDK project and Java Community Process. It's also worth checking out the Java mailing lists.
The best would be through the dev lists: mail.openjdk.org/mailman/listinfo
Of course we do monitor other locations like here, r/java, and other social media outlets.
I wish I could find the video, but I remember Mark Reinhold (Chief Java Architect) gave a great answer on providing feedback. And in short, there is an importance of building relationships. Going to the dev lists and posting your vehement disagreement with for example unnamed variables ("_"), I'm not saying it will be ignored, but the threshold for which that feedback would be acted upon will be very high.
Imagine a new developer coming into your organization, and their first action is giving an explanation as to why something is wrong, or how something should be done differently. The threshold on which you'd act on that feedback would probably be high, certainly if the feedback is unassailably "correct" you'll no doubt act upon it, but chances are there are reasons why a system looks the way it looks, or why processes the way they are. The reasoning for that might become clearer if that developer had spent time fixing bugs, adding new features, or doing updates, to the system, which might also then help not only in providing feedback, but also how that feedback would be received.
There is also this answer from Brian Goetz that somewhat touches on feedback as well: th-cam.com/video/JehEnHGqOTY/w-d-xo.html
Generally speaking, the mailing lists are the way to go for feedback: mail.openjdk.org/mailman/listinfo Feedback is most valuable when it comes from practical experimentation with a preview features - for such cases, the specific mailing list is mentioned in the respective JEP.
implicit import of java.base is absurd... makes new people to learn Java even harder.. why sometimes you need it and sometimes you dont.... no one cares about demos guys.. java is not for demos... please remove this meaningless features that add complexity.
Trying to gatekeep learning? Your job security at risk?
@@waterdudedev nope in fact trying to help the learning process. By trying to do something more simple for a demo, is not making it more simple for learning, because then you have to explain the differences and when and what and module imports and everything and bam - complexity 101
It’s ramping up and adding small concepts little by little, you don’t need to know it when you just want something small running.
If you're a teacher working with students and want to teach them how to work with Lists or Maps, not having to handle where to import those classes from, or even imports at all, can help keeping the focus of working with data structures and not going down unrelated topics like imports.
It's particularly helpful in a learning setting because, al most by definition, the students will not yet be familiar with the package structure of the JDK or how to use their IDE to look up.resolve imports.
Certainly IDEs are much more powerful now, but I remember struggling with that while I was in school some years ago now learning Java.
@@billykorando its far better if this is only in jshell since i will probably use it to show structures or streams (io) or nio or etc but in a java file to somehow have auto modules imported but the moment you add a class they are not and why is that and why this module is imported but the other is not and why the hell we also have packages and real modules like module-info … its getting more compex not streamlined
Averages are nonsense, Gil covered that extensively for years now. Stop using average pause time especially in context of GC of all things... average will completely hide a massive highest pause time.
ZGC is actually awesome though.
Nicolai only mentions averages, but the chart he shows does also include maxes as well.
@@billykorando good point, didn't zoom into the chart but i mean in general people should forget about "averages"
@@krellin perhaps, as Nicolai eludes to it would depend upon use case. For applications that will be interacting with human users, yea max pause times are a very important consideration.
For a batch application, average pause time might be more relevant, within certain constraints.
It’s been awhile since I have seen the presentation you mention, but I doubt Gil was suggesting “ignore average pause entirely”, but rather don’t over focus on it as it can be (very) misleading.
@@billykorando oh yes he was, and he demonstrated how average can tell you things are improving while they don't... very recently i saw it for myself on a real system...
basically only actually useful thing for me was better switch statements
still 0 reason to go back to java from kotlin
FFM is nice too but needs testing to see if they are actually doing it faster...
Preach, Kotlin is just so much better... after working with it for a couple of years it just feels so much better than Java in every way possible. Kotlin MP especially has been a game changer for my productivity
@@Zoumath if java language devs did their job (or their managers) kotlin would not exist...
People who worked on JVM though did a fantastic job.
@@krellin The Java language had a pretty slow period for a decade or so between about 2005 to 2015 which left room for Kotlin. They've now changed how they manage Java, and advancements are coming quicker. Java is adopting many of the best parts of Kotlin and other languages. But Java is not the place for bleeding-edge language innovation, so if that's what you're looking for, you're probably better off with a different language. Personally, I like that they're taking their time and learning from other languages.
@@prdoyle they started innovating only because jetbrain started becoming a threat... we would still be sitting at java 8 probably.
Also no i do not think they are close to adopting good practices. One of the most infuriating changes was their stupid java record classes... which for some reason have to be immutable... where in the world did someone define an immutable pojo? this is for message passing protocols, even there you dont really carea bout immutability.
Kotlin is all about giving you options, and you picking what makes sense, but they insist on shoving their bias into language.
Immutability is wasteful, terrible for performance and forces all the useful data to get out of cpu caches... and becuase most poeple are incompetent they will use java records as easier way to define pojos (data classes for kt)... now i have to deal with bunch of stupid issues that this brings.
Most of the features they are doing imo are in meh category... i dont think markdown is considered innovation... instead of this bs they could go and revamp many poor choices they did in java NIO riddled with stupid locks and synchronizations...
Don't forget about Scala. Many of the features in Kotlin and that have added recentlyin Java come from Scala.