For the non-virtual case, I think it should defer to Jetty by passing a null ThreadFactory, which then uses itself[1] for the ThreadFactory and will honor the name[2].
For the virtual case, call name on the builder[3]?

[1] https://github.com/jetty/jetty.project/blob/jetty-10.0.20/jetty-util/src/main/java/org/eclipse/jetty/util/thread/QueuedThreadPool.java#L180
[2] https://github.com/jetty/jetty.project/blob/jetty-10.0.20/jetty-util/src/main/java/org/eclipse/jetty/util/thread/QueuedThreadPool.java#L907
[3] https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.Builder.html#name(java.lang.String,long)

@mattnelson I don't like using different patterns for the two thread types. If Jetty would update the naming pattern, the threads names would differ, if someone enables virtual threads. Then I'd vote for simply using the current Jetty naming scheme and implementing the thread naming ourselves. Then the thread names would be consistent between virtual and non-virtual ones.

I agree with @zUniQueX. I came to this thread as I had noticed this too. In my opinion, the custom thread naming is definitely super useful, especially when using something like Visual VM for debugging. Plenty of other libraries don't really do thread naming properly and filtering for (or out) dw* is easier "pool-something" because lots of other things just use the default naming. It also helps with identification within logs.

I don't like using different patterns for the two thread types

I was not advocating for that. The thread name should be consistent regardless of virtual or not. My suggestion to pass null to QueuedThreadPool is because QTP is already an instance of ThreadFactory, so in the non-virtual case the extra ThreadFactory object is not needed.

I'm wondering if the current implementation should be refactored due to adding first class virtual thread support in 10.0.12 > jetty/jetty.project#8360

@zUniQueX can this be targeted to 5.x?

@mattnelson I've been quite busy over the last weeks, so I didn't have much time to dig into this. I'd appreciate a PR for this, if you've got the time.