Synchronous executor interface

[Robert Engels]

I also still don’t understand this. virtual threads are moving Java to synchronous - they are moving it back to original Java with thread as the unit of execution. This wasn’t needed before async arrived and it isn’t needed now. Use standard Java thread based concurrency patterns. 

> On Aug 8, 2023, at 4:55 PM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> Hi.
> 
> I think what you’re saying is that you’d like the JDK to include a functional interface for the type Supplier<T> –> T. While I do see the logic in that, I think that Function<Supplier<T>, Supplier<T>> is not much more cumbersome to use (i.e., instead of `se.submit(action)` you’ll write `mapper.apply(action).get()`) and has the benefit of being composable.
> 
> So I think your idea has merit, but I think at this point we’ll wait and see what coding patterns emerge before adding such a type or until the JDK itself requires it.
> 
> — Ron
> 
>> On 6 Aug 2023, at 06:09, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
>> 
>> Hi,
>> 
>> Loom wants to do away with most of the asynchronous code, but in many cases, the asynchronous invocation was abstracted behind an Executor(Service). However, often executors have a multiple purpose: Most notably, you want to limit concurrency. Since many library code do not actually want to bother deciding how to limit the execution (or what context the tasks should run in), they offer the client code to pass the executor implementation.
>> 
>> Now that Loom is pushing us toward synchronous code, we are actually left without an executor abstraction, which I believe should be provided by the JDK rather than every library creating its own. So, I propose a new interface (and maybe a few obvious implementations) to be added to JDK. For example, the new executor interface could look like this:
>> 
>> ```
>> interface SynchronousExecutor {
>>  <T> T execute(Supplier<? extends T> action);
>> 
>>  default <T> T execute(Runnable action) {
>>    return execute(() -> { action.run(); return null; });
>>  }
>> }
>> ```
>> 
>> Of course, in this case a new checked exception aware variant of Supplier / Runnable would also be nice to lessen the problem with checked exceptions. (on side note: it is also quite regrettable that it can't be a functional interface ...)
>> 
>> Also, 4 commonly useful implementations could be:
>> 
>> - Just immeditaly call the the passed action.
>> - Limit concurrency using sempahore.
>> - Set scoped values for the provided action.
>> - Combine multiple executors into one.
>> 
>> Attila
>> 
>