Почему Scala создает собственный ForkJoinPool вместо использования java.util.concurrent.ForkJoinPool # commonPool?

Question

Java и Scala представляют свои собственные глобальные ForkJoinPool, Java как java.util.concurrent.ForkJoinPool#commonPool и Scala как scala.concurrent.ExecutionContext#global.Кажется, что оба они предназначены для использования в одних и тех же случаях, в частности для запуска неблокирующих параллельных задач (часто неявно).Теперь, насколько я могу судить, если вы неправильно выберете свои взаимодействия, вы получите два пула потоков, которые будут выполнять одно и то же: один для мира Java и один для мира Scala.

Итак, если я не пропускаю что-то очевидное, есть ли у Scala веская причина не просто использовать Java commonPool для своего глобального ExecutionContext?

Answer 1

Чтобы добавить к другим ответам - помимо проблемы с версией JVM, использование конкретной реализации JVM связывало бы Scala API с внутренними компонентами Java.Даже если изначально это не было целью, сейчас сообщество Scala хотело бы нацелиться на несколько бэкэндов: у нас есть Scala, Scala.js, Scala Native.Если мы решим что-то изменить и соединить библиотеку Scala с кодом API JVM, то это будет менее переносимым без веской причины - в конце концов, ExecutionContext в JVM все еще использует некоторые реализации пула потоков Java для внутреннего использования, поэтому мы не изобретаем колесо заново.

Answer 2

ForkJoinPool был представлен в Java 7 , поэтому никакая JVM под 1.7 никогда не сможет вызвать его. Чтобы запускать программы Scala, работающие на <1.7 VM, в то время это было необходимо; В настоящее время, когда мы достигли EOL для JVM под 1.8, я полагаю, что поддерживать этот кусок пирога не нужно, поскольку каждая JVM, в которой работает Scala, должна включать классы / пакет Java.

Также обратите внимание на некоторые другие изменения , внесенные в пул, поскольку этот ответ утверждает.