<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">That’s the point. It is an abstraction that allows flexibility. You have the same concern if your sync blocks on a semaphore indefinitely. </div><div dir="ltr"><br></div><div dir="ltr">Your “guarantee” of synchronous in your api is not a guarantee. The constraints are under specified. It would be up to the implementation. Similarly - a synchronous Executor is trivial - and how it works it based on the specific implementation. </div><div dir="ltr"><br><blockquote type="cite">On Aug 8, 2023, at 10:07 AM, Attila Kelemen <attila.kelemen85@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">robert engels <<a href="mailto:rengels@ix.netcom.com">rengels@ix.netcom.com</a>> ezt írta (időpont: 2023. aug. 8., K, 1:52):<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">But why not? Future is pervasive - and then the user can easily switch between synchronous executors and async executors with no user code change - and 0 changes to the JDK.<div><div><div><br></div></div></div></div></blockquote><div><br></div><div>Because Future does not convey the idea that it must be synchronous (in fact, it hints otherwise), and doing something like this is dangerous for async executors, because it is often hard to argue about the context you are called in:</div><div><br></div><div>```</div><div>// ExecutorService executor</div><div>var result = executor</div><div> .submit(() -> whatever_action)</div><div> .get();</div><div>```</div></div></div>
</div></blockquote></body></html>