support creating ForkJoinPools with maximumPoolSize

[pjfanning]

ForkJoinPool has extra contructors in JDK9+ that allow maximumPoolSize to be set.

Relates to #482

Pekko still supports JDK8 so implementing this is not straightforward.

Options include:

• adding a new dispatcher executor type of fork-join-executor-jdk9 which is similar to fork-join-executor but supports the extra maximumPoolSize config (the class for this could be added to jdk9+ build (we support having a scala-jdk9 source directory)
• have fork-join-executor support the maximumPoolSize but ignore it or fail if Java 8 runtime is used. We might need to use Java reflection to do this.

[mdedetrich]

I think it makes sense to solve this when we get multi-jar-release working so we can target jdk 9+ in a principled fashion. For this reason I think removing it from the 1.1.0-M2 milestone makes sense as I seriously doubt that we will get multi-jar-release working by then, @He-Pin @pjfanning do you agree?

[He-Pin]

IIRC, the multi-jar-release has bad IDE support, and @Glavo once told me about that too, for me the current implementation seems good, so does netty work this way, another library like reactor-core is using the multi-jar-release mechanism.

[pjfanning]

I don't believe in dropping useful features because one implementation that can't be done is preferred over one that is ready to go.

[mdedetrich]

I am not saying that the feature should be dropped in general, just that the current implementation has a lot of unanswered questions and considering that the version with multi-jar-release would be trivial in comparison that might be preferrable.

Also since we are dealing with JDK9 specifically, we have machinery in place in Pekko to compile classes just for JDK 9

IIRC, the multi-jar-release has bad IDE support

IDE support is low priority compared to everything else and the version with reflection is much harder to understand/read code wise.

[He-Pin]

@mdedetrich Netty's PlatformDependent0 is doing the same, I don't think multi-jar-release should be a blocker for this, What about android? multi-jar-release can not ensure the code will work on Android too.

[mdedetrich]

multi-jar-release can not ensure the code will work on Android too.

Android supports JDK 1.8+ which means it will ignore java 9 compiled classes in the multi-release-jar (its the java-9 compiled classes which will be a non standard location).

In other words it will work fine

I don't think multi-jar-release should be a blocker for this

I am not saying that its a blocker, just that multi-jar-release may already be done before the feature is complete

[He-Pin]

Some methods are missing on Android, AFAIK, we will see.

[He-Pin]

@mdedetrich It will be contagious when user packaging shadow jars, @Glavo just told me。

[pjfanning]

@mdedetrich It will be contagious when user packaging shadow jars, @Glavo just told me。

I don't think this is a good reason not to use MR jars. Good shading tools support MR jars.

[pjfanning]

We already depend on jackson-core which is an MR jar.

[mdedetrich]

@mdedetrich It will be contagious when user packaging shadow jars, @Glavo just told me。

I don't think this is a good reason not to use MR jars. Good shading tools support MR jars.

Agreed, I don't know what the aversion to multi release jar's comes from but its well support and a lot of critical Java OS libraries use it.

The issues currently with multi release jar's are more sbt specific and this is largely a historical artifact (which is that any new functionality in later JDK's typically had their own equivalent idiomatic Scala specific solution so there wasn't much incentive to support multi-release-jars in sbt as there was very little demand for it).

[pjfanning]

@He-Pin I'm open to pressing to get this into 1.1. My view is that user need outweighs implementation niceties. Do you need this change?

[He-Pin]

@pjfanning Yes， I'm using Pekko in several of our mission-critical systems, so I would like to keep my systems safe. If we like, we can re-implement it later with multi-jar-release.