Wow, that's impressive. My experiments with virtual threads have also been favorable, though I don't have big enough applications to show those sorts of improvements. Thanks for the info
@@talesfromthejarside Of course, one can argue that something was wrong before. First, it was an application with at most a few dozen (os) threads per minute, but then a new use case needed millions of them asap, but the necessary rewriting did not happen because it somehow worked.
Great summary - agree big time with the shell rating. Never used it and not missing it either. tbh I work 99% in Spring env, so the HTTP client is pretty much optional for me. TextBlocks is a major feature in my world. Building a lot of rather large json payloads and then testing the app with that - text block is pure magic!
20:19 IMHO such a benefit in the platform is a big deal, even if I don't use the feature directly! The big story with the system-level features like virtual threads (and somewhat, with modules) is that Java is looking beyond feature-parity with C#: they are looking at Node/Javascript for areas to improve. This is true with respect to throughput metrics, start-up times, binary footprint, and release cadence (IMHO modules and cleaning up the JDK facilitates faster feature development).
super-fun video: thank you! Some comments: (a) I also encourage everyone to read Brian Goetz' article on data-oriented programming, which combines several features into a unified idea. (b) The history of modules, as Ken surely knows, is more complicated, as the OSGi initiative (re: bundles) was getting traction circa 2010, and there were other competing ideas as well. The Java team decided to do their own spec, and _then_ start with the JDK, which took a long, long time. There was serious debate in the community over this; pundits wondered if it would ever be complete (and the OSGi camp was incensed that their work wasn't being used). Java 9 was _finally_ the end result. If the Java team had waited longer, it would have only extended the uncertainty and acrimony. I do agree that adoption and impact seems to be quite low.
Right. The way I remember it, there were members of both the OSGI and the JBoss modules teams on the committee. I think the result was good. It's just that most devs didn't realize they could upgrade and safely ignore modules if they wanted to. Thanks for the comment!
@@koncz314 well that would have meant no virtual threads. Java modules for the JDK is absolutely essential for that as has been pointed out on numerous occasions. The JDK from before was an unmaintainable mess that got reined in by modules. Modules outside the JDK needs to speed up but luckily it is happening albeit slowly. Try out avaje inject for example. No need for reflection magic to have DI. Now spring adopting moduels can hoepfully speed things up a bit. 😊
The idea of virtual thread is that u end up writing sync code but enjoy async behaviour, rather than using is async await everywhere, now from server side point spring boot 3 and most of other framework supports virtual thread by just adding one property and thats it ur existing code can scale better . Although I definitely agree with the structure concurrency part which hopefully we will get in GA by Java 25 🤞.
I don't think this video can be useful for experienced Java developers, but it would be useful for those studying Java and preparing for interviews. Unfortunately, the video lacks examples of each feature. Anyway, thank you for your work.
Oof. I knew I overlooked something. I'm not sure what a good icon would be for that, too. :) Mostly I use the getFirst() method out a lot on lists, so I would put sequenced collections at the "Okay" level, because it does exactly what I expected. Thanks for noticing.
I find records to be an anemic and insufficient replacement for lombok. Sure, once you consider pattern matching it's now useful, but otherwise? Nah. Virtual threads are huge. Even if you are just doing a request/response (with no meaningful concurrency control between requests) you'll scale far better. Getting the benefits of reactive w/o the learning curve shouldn't be overlooked. Its one of the rare things i think java's solution is *better* than async/await, co-routines, etc. Its essentially transparent (everything in java has an asterisk) Modules are so you can now treat logical boundaries the same as physical. i.e. all the separation of microservices but with the low price of a monolith. I'd agree it was a dollar short and a day late, but i love the idea. Kind of obnoxious things like spring modulith don't even leverage it.
another thing about jigsaw is that although it supports modules AFAIK it does not support version numbering, meaning you can't specify what version you require which is one major minus, and still might give you jar hell, oracle killed java 9 as soon as they decided with their dumb money grabbing scheme of release versioning of every 6 months, no one would upgrade to a version which would be killed in 6 months, and they probably knew that.
Yeah, version numbering in modules is definitely an issue, which I think OSGI handles. I don't mind the six-month release schedule, though, or maybe I'm just used to it by now. Most companies only care about the LTS releases anyway.
@@talesfromthejarside you need to remember that when 6 months schedule was released there was NO free LTS TCK jvm's available, and java 8 LTS was declared to be end of life in a year (and afterwards it would paid) , so you had to pay up, when i saw this, i've figured it would be the end of java as no company would risk trusting them again, corretto literally saved this. not to mention breaking backwards compatibility, consider that jaxb was removed from the jvm because it was thought of as j2ee technology , buy then they went and inserted HTTP client on java 11? cause that's not j2ee? for the record i've thought about replacing our commons http client for that, but then i remembered we also used http server in our j2se server, so what's the point .
Honestly? Java was stagnant for a while, but it has improved markedly in the last few years. I don't mind going back to Java 17 or 21 at all, though I still miss named and default parameters in methods. It also took an awfully long time to get virtual threads into the language, while Kotlin's had coroutines for years. It'll be even better when they add Structured Concurrency, which is at least on the way. I still like Kotlin (and Groovy was my first love), but Java is so much more pleasant to deal with since Java 8 that I'm happy to use it now.
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
Your videos are adventurous and informative at the same time . Thanks for sharing!
looking at the changelog of anything is a huge stepping point into mastering it and this helped a lot, although I did have to take a lot of notes lol
Virtual threads are in my firts tier, for sure. A very small change in my code safed me up to 5/6 of running time in a critical application!
Wow, that's impressive. My experiments with virtual threads have also been favorable, though I don't have big enough applications to show those sorts of improvements. Thanks for the info
@@talesfromthejarside Of course, one can argue that something was wrong before. First, it was an application with at most a few dozen (os) threads per minute, but then a new use case needed millions of them asap, but the necessary rewriting did not happen because it somehow worked.
Great summary - agree big time with the shell rating. Never used it and not missing it either. tbh I work 99% in Spring env, so the HTTP client is pretty much optional for me.
TextBlocks is a major feature in my world. Building a lot of rather large json payloads and then testing the app with that - text block is pure magic!
Great job. I agree with assessments. JMS is good for JavaFX to adding the Java FX components on the Java statement.
20:19 IMHO such a benefit in the platform is a big deal, even if I don't use the feature directly! The big story with the system-level features like virtual threads (and somewhat, with modules) is that Java is looking beyond feature-parity with C#: they are looking at Node/Javascript for areas to improve. This is true with respect to throughput metrics, start-up times, binary footprint, and release cadence (IMHO modules and cleaning up the JDK facilitates faster feature development).
Most of my interaction with modules so far has been when they get in my way and I have to work around them.
Yeah, I hear that. I haven't seen any real benefit from them either
super-fun video: thank you! Some comments: (a) I also encourage everyone to read Brian Goetz' article on data-oriented programming, which combines several features into a unified idea. (b) The history of modules, as Ken surely knows, is more complicated, as the OSGi initiative (re: bundles) was getting traction circa 2010, and there were other competing ideas as well. The Java team decided to do their own spec, and _then_ start with the JDK, which took a long, long time. There was serious debate in the community over this; pundits wondered if it would ever be complete (and the OSGi camp was incensed that their work wasn't being used). Java 9 was _finally_ the end result. If the Java team had waited longer, it would have only extended the uncertainty and acrimony. I do agree that adoption and impact seems to be quite low.
Right. The way I remember it, there were members of both the OSGI and the JBoss modules teams on the committee. I think the result was good. It's just that most devs didn't realize they could upgrade and safely ignore modules if they wanted to.
Thanks for the comment!
Making jigsaw instead of adopting the already existing OSGi solution (not the whole spec) was a mistake.
@@koncz314 well that would have meant no virtual threads. Java modules for the JDK is absolutely essential for that as has been pointed out on numerous occasions. The JDK from before was an unmaintainable mess that got reined in by modules. Modules outside the JDK needs to speed up but luckily it is happening albeit slowly. Try out avaje inject for example. No need for reflection magic to have DI. Now spring adopting moduels can hoepfully speed things up a bit. 😊
The idea of virtual thread is that u end up writing sync code but enjoy async behaviour, rather than using is async await everywhere, now from server side point spring boot 3 and most of other framework supports virtual thread by just adding one property and thats it ur existing code can scale better . Although I definitely agree with the structure concurrency part which hopefully we will get in GA by Java 25 🤞.
Don’t you also have green threads now in Java? I mean like lightweight threads similar to what we have in Golang.
Nice overview of Java changes.
Glad you liked it!
this is the kind of content I like, thanks a lot.
Glad you liked it :)
great summary thanks
I don't think this video can be useful for experienced Java developers, but it would be useful for those studying Java and preparing for interviews. Unfortunately, the video lacks examples of each feature. Anyway, thank you for your work.
well done, could you do a video for this data driven programming? It could be interesting seeing it together with java 21
One is in the works :-)
Great video!
Please do a video about
data oriented programming introduced by brian getz
I have an app ready. I'm working on a title and thumbnail that describes it without getting way too wordy
Sequenced Collection? Where you put it?
Oof. I knew I overlooked something. I'm not sure what a good icon would be for that, too. :) Mostly I use the getFirst() method out a lot on lists, so I would put sequenced collections at the "Okay" level, because it does exactly what I expected. Thanks for noticing.
@@talesfromthejarside thanks for sharing that.
I find records to be an anemic and insufficient replacement for lombok. Sure, once you consider pattern matching it's now useful, but otherwise? Nah.
Virtual threads are huge. Even if you are just doing a request/response (with no meaningful concurrency control between requests) you'll scale far better. Getting the benefits of reactive w/o the learning curve shouldn't be overlooked. Its one of the rare things i think java's solution is *better* than async/await, co-routines, etc. Its essentially transparent (everything in java has an asterisk)
Modules are so you can now treat logical boundaries the same as physical. i.e. all the separation of microservices but with the low price of a monolith. I'd agree it was a dollar short and a day late, but i love the idea. Kind of obnoxious things like spring modulith don't even leverage it.
it's awesome)
Thanks 😊
another thing about jigsaw is that although it supports modules AFAIK it does not support version numbering, meaning you can't specify what version you require which is one major minus, and still might give you jar hell, oracle killed java 9 as soon as they decided with their dumb money grabbing scheme of release versioning of every 6 months, no one would upgrade to a version which would be killed in 6 months, and they probably knew that.
Yeah, version numbering in modules is definitely an issue, which I think OSGI handles. I don't mind the six-month release schedule, though, or maybe I'm just used to it by now. Most companies only care about the LTS releases anyway.
@@talesfromthejarside you need to remember that when 6 months schedule was released there was NO free LTS TCK jvm's available, and java 8 LTS was declared to be end of life in a year (and afterwards it would paid) , so you had to pay up, when i saw this, i've figured it would be the end of java as no company would risk trusting them again, corretto literally saved this.
not to mention breaking backwards compatibility, consider that jaxb was removed from the jvm because it was thought of as j2ee technology , buy then they went and inserted HTTP client on java 11? cause that's not j2ee? for the record i've thought about replacing our commons http client for that, but then i remembered we also used http server in our j2se server, so what's the point .
What you might call... Java script 🥁
😊
Oh, you are a kotlin guy? Tell me from your perspective, is java doing good enough?
Honestly? Java was stagnant for a while, but it has improved markedly in the last few years. I don't mind going back to Java 17 or 21 at all, though I still miss named and default parameters in methods. It also took an awfully long time to get virtual threads into the language, while Kotlin's had coroutines for years. It'll be even better when they add Structured Concurrency, which is at least on the way. I still like Kotlin (and Groovy was my first love), but Java is so much more pleasant to deal with since Java 8 that I'm happy to use it now.