These are arguments against the implementation, not the actual utility of the framework. One can have ugly internal implementation (which sometimes is unavoidab

These are arguments against the implementation, not the actual utility of the framework. One can have ugly internal implementation (which sometimes is unavoidable because you're solving hard problems), but clean interfaces. Regardless, Doug Lea anticipated these complaints in the comments to his code: * Style notes * =========== * * Memory ordering relies mainly on VarHandles. This can be * awkward and ugly, but also reflects the need to control * outcomes across the unusual cases that arise in very racy code * with very few invariants. All fields are read into locals * before use, and null-checked if they are references. This is * usually done in a "C"-like style of listing declarations at the * heads of methods or blocks, and using inline assignments on * first encounter. Nearly all explicit checks lead to * bypass/return, not exception throws, because they may * legitimately arise due to cancellation/revocation during * shutdown. * * There is a lot of representation-level coupling among classes * ForkJoinPool, ForkJoinWorkerThread, and ForkJoinTask. The * fields of WorkQueue maintain data structures managed by * ForkJoinPool, so are directly accessed. There is little point * trying to reduce this, since any associated future changes in * representations will need to be accompanied by algorithmic * changes anyway. Several methods intrinsically sprawl because * they must accumulate sets of consistent reads of fields held in * local variables. There are also other coding oddities * (including several unnecessary-looking hoisted null checks) * that help some methods perform reasonably even when interpreted * (not compiled). I find the "Calamity" article disingenuous. If you read more of the comments, Lea clearly explains the source of many of his data structures and gives an overview of how it all works.