Some Review of the EA build

[Alan Bateman]

On 30/06/2020 17:30, Daniel López wrote:
> Would it be feasible to add a flag to the ExecutorService factory methods
> so they return their virtual implementation counterparts for the sake of
> "brute force" testing?
> One of the main issues getting people to test is that a majority of people
> get to use threads/pools of threads through third party libraries,
> "applications servers" or containers that handle the creation of threads
> for them. So, even though many might be willing to have a go at it, the
> testing they can perform is quite limited. On the other hand many of those
> libraries etc. use the already existing methods so changing the
> implementation under the hood and returning virtual threads would require
> no new versions of those artifacts and would facilitate other people's
> testing. It won't be perfect testing, by far, and it might cause many false
> positives, but it might help detect some glaring issues before artifact
> creators get to update their code.
>
> I, for example, usually develop web apps that create a handful of threads
> for various reasons, but the main "thread handler" in my day to day is
> Jetty, embedded as servlet container, so testing with changes in the code I
> control would yield very small benefits. OTOTH, if I can simply run the JVM
> with a flag that gets jetty to use virtual threads, I can test quite a bit
> more of my everyday life, right now. At least even if just to check that
> "if Jetty changed everything to virtual threads, it would not break".
>
Jetty is easy to setup so that it start a new virtual tread to handle a 
HTTP request. It has its own ThreadPool that implements Executor (rather 
than ExecutorService) and you just implement it and specify it to the 
Server constructor. So yes, your suggestion is reasonable, it's just 
some of servers and frameworks seem to have their own thread pool classes.

-Alan