3 ms·

There are some fairly major Java backend libraries that are founded almost entirely on async-type APIs. Eg, Vertx, Quarkus, Micronaut, etc. I am interested to

by kitd 3y ago

There are some fairly major Java backend libraries that are founded almost entirely on async-type APIs. Eg, Vertx, Quarkus, Micronaut, etc. I am interested to see how a widespread move to virtual threads, which for them is somewhat existential, affects their futures (pun intended). Also what backend libs that are founded on virtual threads emerge and supplant them.

samus 3y ago
In principle, reactive and callback-style libraries could eventually use Virtual Threads as backend as well, but I expect for them to fall out of fashion. After all, they were introduced because the existing threading support in Java did not adequately support massively-concurrent applications. There will surely be new frameworks that will take advantage of Virtual Threads and will eventually require to run on the first Java LTS version with Virtual Threads support. Other projects might offer Virtual Threads as a backend, maybe even by default, but will continue to support traditional backends for the foreseeable future, e.g., Apache Tomcat.
gabereiser 3y ago
Not sure about now but a few years back the company I worked for was heavily vested in Finagle [1] using Future<T> pools. I'm sure virtual threads would only enhance this framework. Also, Spring and it's reactive webflux would probably benefit as well [2]. [1] https://twitter.github.io/finagle/ https://twitter.github.io/finagle/ [2] https://docs.spring.io/spring-framework/reference/web/webflux/reactive-spring.html https://docs.spring.io/spring-framework/reference/web/webflu...
killingtime74 3y ago
Quarkus is built on Vertx so once that gets upgraded two will support it. https://github.com/vert-x3/vertx-virtual-threads-incubator https://github.com/vert-x3/vertx-virtual-threads-incubator Vertx is testing it
ye-olde-sysrq 3y ago
I actually used Jetty for a recent project because they were one of the first to integrate support for running handlers on virtual threads.
jmaker 3y ago
Just to add some context, Micronaut 4 supports VTs (via the blocking scheduler), while Quarkus runs on Vert.x, which in turn runs on Netty. There’s also Helidon, in which Nima has become an alternative to Netty as a server. This topic was also discussed by the Spring/VMware guys behind Reactor and Spring WebFlux, which also runs on Netty rather than Tomcat. So in this scope it’s interesting to see how JDBC and Tomcat adapt to VTs. In the end, asynchrony and fibers are different perspectives at concurrency management. What I hope is that most people use them as complementary approaches. Lots of companies have used blocking Tomcat underneath and we’re content with it. With VTs they just got a free opt-in performance upgrade. Reactive streams have been perceived by many community members as something overly complicated. So VTs will most likely be warmly welcomed as soon as they trickle through to the production code bases. Most of the team leads I spoke with recently expressed a happy grin when talking about VTs in the context of their blocking codebases.
geodel 3y ago
It is often very difficult for old established frameworks, libraries to move to new/improved ways of programing language. Besides usual reason of downstream breakage, technical challenge, timing etc, critically, they reflect project founders' self-image. So most projects found it more worthwhile to justify current choices at any cost rather than try new things with open mind.

by kitd 3y ago

samus 3y ago

In principle, reactive and callback-style libraries could eventually use Virtual Threads as backend as well, but I expect for them to fall out of fashion. After all, they were introduced because the existing threading support in Java did not adequately support massively-concurrent applications. There will surely be new frameworks that will take advantage of Virtual Threads and will eventually require to run on the first Java LTS version with Virtual Threads support. Other projects might offer Virtual Threads as a backend, maybe even by default, but will continue to support traditional backends for the foreseeable future, e.g., Apache Tomcat.

gabereiser 3y ago

Not sure about now but a few years back the company I worked for was heavily vested in Finagle [1] using Future<T> pools. I'm sure virtual threads would only enhance this framework. Also, Spring and it's reactive webflux would probably benefit as well [2]. [1] https://twitter.github.io/finagle/ https://twitter.github.io/finagle/ [2] https://docs.spring.io/spring-framework/reference/web/webflux/reactive-spring.html https://docs.spring.io/spring-framework/reference/web/webflu...

killingtime74 3y ago

Quarkus is built on Vertx so once that gets upgraded two will support it. https://github.com/vert-x3/vertx-virtual-threads-incubator https://github.com/vert-x3/vertx-virtual-threads-incubator Vertx is testing it

ye-olde-sysrq 3y ago

I actually used Jetty for a recent project because they were one of the first to integrate support for running handlers on virtual threads.

jmaker 3y ago

Just to add some context, Micronaut 4 supports VTs (via the blocking scheduler), while Quarkus runs on Vert.x, which in turn runs on Netty. There’s also Helidon, in which Nima has become an alternative to Netty as a server. This topic was also discussed by the Spring/VMware guys behind Reactor and Spring WebFlux, which also runs on Netty rather than Tomcat. So in this scope it’s interesting to see how JDBC and Tomcat adapt to VTs. In the end, asynchrony and fibers are different perspectives at concurrency management. What I hope is that most people use them as complementary approaches. Lots of companies have used blocking Tomcat underneath and we’re content with it. With VTs they just got a free opt-in performance upgrade. Reactive streams have been perceived by many community members as something overly complicated. So VTs will most likely be warmly welcomed as soon as they trickle through to the production code bases. Most of the team leads I spoke with recently expressed a happy grin when talking about VTs in the context of their blocking codebases.

geodel 3y ago

It is often very difficult for old established frameworks, libraries to move to new/improved ways of programing language. Besides usual reason of downstream breakage, technical challenge, timing etc, critically, they reflect project founders' self-image. So most projects found it more worthwhile to justify current choices at any cost rather than try new things with open mind.