No objections after a few days. I think this can keep moving forward. If no vote is required to be taken, shall we just get on with merging the associated PR?
On Tue, Apr 14, 2026 at 2:49 PM Maytas Monsereenusorn <[email protected]> wrote: > +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] > > >> > > >> > > >
