Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Define protocol for async task execution
    • (defprotocol Executor (exec `[e task]))
  • Provide several implementations
    • for ThreadPoolExecutor
    • for ForkJoinPool 
      • Repackage jsr166y into our own packages (put in Clojure 1.6)
      • Allow user to use jsr166e instead?
      • Use built-in JDK version
  • The general ordering of "bestness" is:
    • JDK 1.6:  jsr166y jsr166y >> Clojure ForkJoinPool >> ThreadPoolExecutor
    • JDK 1.7: jsr166e >> jsr166y >> Clojure ForkJoinPool >> JDK ForkJoinPool
    • JDK 1.8: jsr166e >> JDK ForkJoinPool
    • An ordering that works for everything but JDK 1.8 (where it merely does ok things by default):
      • jsr166e >> jsr166y >> Clojure ForkJoinPool >> JDK ForkJoinPool >> ThreadPoolExecutor
  • Choose default implementation based on environment - try these in order, choosing first one that works:
    • Check for jsr166e.ForkJoinPool (external JDK version) - allow override, JDK 1.7+
    • Check for jsr166y.ForkJoinPool (external JDK version) - allow override, JDK 1.6+
    • Check for clojure.concurrent.ForkJoinPool (Clojure repackaged jsr166y) - always available in Clojure 1.6+
    • Check for java.util.concurrent.ForkJoinPool (JDK built-in version) - always available in JDK 1.7+
    • Fallback to Executor version - always available in JDK 1.6+
  • Allow user to override the implementation we chose with their own custom executor that does whatever they want
    • Done via an "install" api which is presumed to be called prior to system use and updates the executor in an atom

Table of what version you'll get depending on your environment based on the ordering rules above:

Clojure versionJDK versionExternal jarWhatcha getNotes
1.5.11.6noneThreadPoolExecutor 
1.5.11.6jsr166yjsr166y ForkJoinPool 
1.5.11.6jsr166eThreadPoolExecutorJDK 1.6 can't use jsr166e!
1.5.11.7noneJDK ForkJoinPool 
1.5.11.7jsr166yjsr166y ForkJoinPool 
1.5.11.7jsr166ejsr166e ForkJoinPool 
1.5.11.8noneJDK ForkJoinPool 
1.5.11.8jsr166yjsr166y ForkJoinPool 
1.5.11.8jsr166ejsr166e ForkJoinPool 
1.61.6noneClojure ForkJoinPool 
1.61.6jsr166yjsr166y ForkJoinPool 
1.61.6jsr166eClojure ForkJoinPoolJDK 1.6 can't use jsr166e!
1.61.7noneClojure ForkJoinPool 
1.61.7jsr166yjsr166y ForkJoinPool 
1.61.7jsr166ejsr166e ForkJoinPool 
1.61.8noneClojure JDK ForkJoinPoolJDK would be better? 
1.61.8jsr166yjsr166yJDK ForkJoinPoolJDK would be better?1.8 is better than jsr166y here
1.61.8jsr166ejsr166e ForkJoinPool 

...

  • JSR 166 
    • jsr166x - included in JDK 1.6, does not contain ForkJoin
    • jsr166y - compiled with JDK 1.6, included in JDK 1.7. jsr166y jar has fixes past what is in the JDK 1.6.
    • jsr166e - compiled with JDK 1.87, to be included in JDK 1.8. jsr166e jar has fixes past what is in JDK 1.7. 
  • Scala solution
    • Repackage known version of jsr166y as scala.concurrent and include in the Scala language (Akka makes use of it from there)
      • Covers JDK 1.6+ (good) but does not contain the very latest updates for JDK 1.8 that are in jsr166e (bad)
      • When they have a version of Scala that requires JDK 1.7, they will presumably update to jsr166e
    • Akka has pluggable executor providers and using a custom one allows you to make use of jsr166e if you need it