Perhaps I am misreading this, but would this not block the single (traditional) thread managed by scheduler, forcing all such tasks to be run serially even though executorService can use as many (virtual) threads as it likes? (and similarly for the other schedule overload)

While this suggestion looks similar, it does not involve blocking the heavyweight thread as the code here does.

I have not tried it but I suspect the right approach is to create the newSingleThreadScheduledExecutor as here (but preferably passing it a thread factory creating a virtual thread as well), and then implement the schedule overloads something like

class ScheduledCompletableFuture extends CompletableFuture<?> {
    // implement getDelay somehow
}
var scf = new ScheduledCompletableFuture();
scheduler.schedule(() -> {
    var f = executorService.submit(command);
    executorService.execute(() -> {
        try {
            scf.complete(f.get());
        } catch (Throwable x) {
            scf.completeExceptionally(x);
        }
    });
}, delay, unit);
return scf;

@jglick What is the difference between this PR and the suggestion?

The idea is that the platform thread only schedules tasks executed by the virtual threads. Scheduling tasks should not block the platform thread, as the long-running operations are executed by the virtual threads. Or am I missing something?

Ah, I see what you mean. Will look into that.

@jglick It occurs that the ScheduledExecutorService using virtual threads is missing in JDK on purpose. The complexity of handling every corner-case of using the virtual threads for ScheduledExecutorService (the replanning of the tasks to start after the existing task is finished late, error-handling, ...) is too great for now.

I am reverting the ScheduledExecutorService to the platform thread version (#928).

But thank you for reviewing this PR.