title: Is it bad practice to use default common fork/join pool with CompletableFuture for doing long blocking calls?
body: <p>Lets say I have a CompletableFuture which wraps a blocking call like querying a backend using JDBC. In this case, since I am not passing any executor service as a parameter to CompletableFuture.supplyAsync(), the actual blocking work of fetching the resources over backend should be done by a thread within the common Fork/Join pool. <strong>Isn't it <a href="https://zeroturnaround.com/rebellabs/java-parallel-streams-are-bad-for-your-health/" rel="noreferrer">bad practice</a> to have threads from common FJpool do blocking calls?</strong> The advantage I have here is that my main thread isn't blocking, since I'm delegating blocking calls to be run asynchronously. Check abt JDBC calls being blocking <a href="https://dzone.com/articles/myth-asynchronous-jdbc" rel="noreferrer">here</a> . If this inference is true, why do have the option of using default common FJpool with CompletableFuture?</p>
  
  <pre><code>CompletableFuture&lt;List&lt;String&gt;&gt; fetchUnicorns  = 
      CompletableFuture.supplyAsync(() -&gt; {
          return unicornService.getUnicorns();
      });
  
  fetchUnicorns.thenAccept(/**Do something with the result*/);
  </code></pre>