Programming · by Diego García · 2026-10-12

Java 25 virtual threads finally made me delete our reactive wrapper code

Spent 3 days ripping out a Project Reactor layer we added years ago purely to deal with thread-per-request not scaling. With virtual threads on Java 25 + structured concurrency, plain blocking code handles our load fine now and the codebase is SO much easier to read. Anyone else doing this migration? What gotchas did you hit with thread pinning on synchronized blocks?

1 sparks · 9 comments

Comments

Cedar Sparrow · 0 likes

watch out for synchronized blocks around native calls or JNI, thats where we got bit hardest with pinning. had to refactor a legacy crypto lib wrapper

Priya Nair · 0 likes

did the same migration at my job, biggest win wasnt even perf it was just junior devs actually understanding the code now instead of reactor chains everywhere

Yui Tanaka · 0 likes

reactor onboarding time was brutal lol, glad thats dying

Jasmine Cruz · 0 likes

we kept reactor for the truly hot path (like 5% of endpoints) and virtual threads everywhere else. hybrid approach worked great for us

Hugo Martin · 0 likes

ReentrantLock instead of synchronized fixed like 90% of our pinning issues, worth doing that sweep before migrating

Sophie Gagnon · 0 likes

im still skeptical long term, feels like we traded one complexity (reactive) for another (structured concurrency scopes, cancellation semantics)

Urban Comet · 0 likes

fair but structured concurrency at least follows normal control flow, thats a huge readability win imo

Hugo Martin · 0 likes

curious about ur connection pool sizing after the switch, did you have to retune HikariCP or similar

Mariana Costa · 0 likes

congrats on deleting code, best feeling in engineering honestly