Just finished reading this article which claims the Java Fork-Join framework is a bad fit for almost any realistic task. He seems to being up some good points but I don't feel qualified to say if he's right or not. To quote the conclusion:

The F/J framework is lacking as an API

  • It is deficient in “characteristics of a good API” (Joshua Bloch)

The F/J framework is severely inadequate as an application service

  • It is only available as an embedded server, no remote object access such as RMI
  • It is only recommended for aggregate data operations.
  • It is only recommended for users with very large data structures (humongous arrays)
  • It is only useful for machines with profuse processors (16+ recommended)
  • It is only useful for one request at a time
  • It is only useful for strictly limited processing (recommended)
    • must be plain (between 100 and 10,000 basic computational steps in the compute method)
    • compute intensive code only
    • no blocking
    • no I/O
    • no synchronization
  • It has no logging or alerting
  • It has no error/stall recovery
  • It has no ability to display/alter the current execution status
  • It relies on academic correctness rather than maintainability
  • It lacks scope
  • Its multi-tasking is faulty
  • It is inefficient
  • It cannot not scale to hundreds of processors
  • It is complex to the point of being incomprehensible
  • There is no user manual, just JavaDoc

The minuscule benefits of the F/J framework do not outweigh

  • the bloat this experiment adds to the Java™ run time for non fork-join users
  • the restrictions for developers looking to parallelize their software especially with JDK1.8

The F/J framework is an inadequate academic experiment underpinning a research paper, not a lightweight framework. It does not belong in the JDK.

Can anyone here with a better understanding of this comment?

  • 2
    see Discuss this ${blog} – gnat Mar 3 '17 at 13:00
  • 1
    Not sure this is really an opinion. The writer brings some solid points. I'm just not sure they're valid and would like clarification from someone more knowledegable. – Johnny Mar 3 '17 at 13:11
  • When i'm reading the description of the framework and author article, I just think that the J/F framework was design for a very few strict purpose (which make him quite light) and very optimized while the author of the article would have expect much more, making me almost think of a silver bullet that include a bunch of things that is not part of the purpose of the framwork but would extends the usage (RMI, ....). – Walfrat Mar 3 '17 at 13:18
  • It has its uses but I have never seen it in the wild. If you don't like it, don't use it. You are not missing anything exciting. – Traubenfuchs Mar 3 '17 at 13:21
  • I assume the (much more usable) threadpools are built on top of it? If so that alone justifies its existance – Richard Tingle Mar 3 '17 at 17:01

The question is adequately answered by this Stack Overflow post: How is the fork/join framework better than a thread pool? There, you will find top-notch answers, written by experts who are very good at explaining the surrounding issues.

(If anyone has expert-level knowledge on this question, please contribute to that Stack Overflow post instead, since other experts had already contributed there.)

(I am not an expert, so there may be errors in my understanding.)

I will point out some of the subtle criticisms there.

Firstly, most introductory articles on Fork/Join Parallelism mistakenly uses an example that is data-parallel. In fact, most of the time, the example used is embarrassingly parallel. There is a large number of data items, with an identical computation to be applied to each one of them; all of these computations are ready-to-execute; none of these computations communicate with each other. When you have an embarrassingly parallel work, it does not matter much how you partition it across threads / CPU cores. Simple implementations might outperform advanced implementations; and considering that the Java community recognizes ease of code maintenance as a virtue, a simple implementation that fulfills the requirement (for such embarrassingly parallel work) should be preferred.

Work-stealing was another controversial feature. Not so in academia - it is unanimously regarded as a good thing. The quality of implementation is another matter, though.

Part of the reason the fork/join framework attracts such criticism is because Java does not use an approach that looks like C#'s async/await, which transforms a single function's source code into a state machine. The capability to perform this transform is important because it allows the transformed object to break out whenever it is blocked. By "break out", what I mean is literally returning from the function call back to the executor service, so that the executor service (thread) can dequeue and execute another ready-to-execute task. This requires the packaging of the remaining yet-to-be-executed code into a task, and this is exactly what an "async state machine" does.

When work-stealing is implemented on an environment that does not transform code into async state machines, the implementers had decided to allow the thread that has been blocked to search for and execute other tasks it could find. There are two dangers. Firstly, there is no guarantee that "the other task it could find" is well-behaving. For example, the current task might be blocked (waiting) for another task that would be finished within a mere tens of milliseconds, whereas "the other task it could find" might keep executing for a minute. Executing that other task on the current call stack means that the currently blocked task may not resume even if its dependent tasks have finished.

In some sense, it deserves some criticism, but the criticism you find on the page that you have linked may have misplaced the root cause of those shortcomings.

It is worth pointing out that the C# "async state machine" was published several years after Java 1.7.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.