+1 from me too. Being able to use virtual threads would be a big plus. Thanks, Maytas
On Tue, Apr 14, 2026 at 12:39 PM Lucas Capistrant < [email protected]> wrote: > I should clarify “wherever possible” was not to say just blindly move > things to use vthreads. But rather to evaluate and execute migration > wherever is a technically sound decision to move that will provide actual > value for performance, operability, or both. > > On Tue, Apr 14, 2026 at 2:32 PM Lucas Capistrant < > [email protected]> > wrote: > > > I guess a first adopter could be to pick some size configurable thread > > pool to migrate. remove the config and use virtual threads. Stating that > > the initial win is reducing cognitive load for an operator by replacing > > config choices with virtual threads wherever possible. Perhaps the pool > in > > LookupReferencesManager if we had to pick something. > > > > On Tue, Apr 14, 2026 at 12:33 PM Clint Wylie <[email protected]> wrote: > > > >> +1 from me, I also would like to explore using virtual threads as soon > >> as possible (without the overhead of trying to build multi-release > >> jars), and java 25 is my real wish for our minimum supported version > >> too so we can at least have all the nice memory stuff from the ffi > >> > >> On Tue, Apr 14, 2026 at 9:52 AM Jesse Tuğlu <[email protected]> wrote: > >> > > >> > > Is there any place you have in mind where you are eager leverage > >> > Java 21 language features? > >> > > >> > This will allow for things like green (virtual) threads and JDK 25 > will > >> > allow for things like FFI, which will help move along the goals > >> mentioned > >> > in: https://github.com/apache/druid/issues/19039. > >> > > >> > > Regarding java25, is that your analysis from initial inspection the > >> Hadoop > >> > docs/code or did you smoke check the compatibility at runtime too? > >> > > >> > I've run JDK 25 on JDK 21-compiled bytecode internally on a test > cluster > >> > and have validated it passes CI. I believe the prior blockers for > >> running > >> > JDK 25 were the incompatibilities with SecurityManager brought in by > >> older > >> > versions of Hadoop. > >> > > >> > On Tue, Apr 14, 2026 at 7:47 AM Lucas Capistrant < > >> [email protected]> > >> > wrote: > >> > > >> > > Thanks for starting the thread, Jesse. I think this is a great idea > >> for > >> > > Druid 38. Is there any place you have in mind where you are eager > >> leverage > >> > > Java 21 language features? A good motivation to share with the > change > >> > > notice helps communicate the benefit of updating our Java support > >> matrix. > >> > > Regardless, I’m on board with it. > >> > > > >> > > Regarding java25, is that your analysis from initial inspection the > >> Hadoop > >> > > docs/code or did you smoke check the compatibility at runtime too? > >> > > > >> > > Thanks, > >> > > Lucas > >> > > > >> > > On Tue, Apr 14, 2026 at 12:08 AM Jesse Tuğlu <[email protected]> > >> wrote: > >> > > > >> > > > Hi folks, > >> > > > > >> > > > Wanted to start a devlist thread to discuss removal of JDK 17 in > >> favor of > >> > > > JDK 21/25 as supported runtimes in Druid 38. The PR for this > change > >> is > >> > > > here: https://github.com/apache/druid/pull/19304. Upgrading to > >> Hadoop > >> > > 3.5 > >> > > > clients enabled <https://hadoop.apache.org/docs/r3.5.0/> the use > >> of JDK > >> > > 21 > >> > > > and, from what I can tell, contains SecurityManager patches that > >> unblock > >> > > > Druid's usage of JDK 25. > >> > > > > >> > > > Best, > >> > > > > >> > > > Jesse > >> > > > > >> > > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> >
