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] >> >>
