Hi! I'm the author of the paper referenced by this post and let me start off by saying that you're right in that the paper didn't do justice to Quasar. I kindly apologies for this. I actually did want to revise that section before submitting, but as usual, the deadline came first and that section remained in my opinion one of the most "hand-wavy" ones.
Mostly the comment about "adding complexity", comes from my own biased experience of working with bytecode instrumentation. I work on the JRebel team @ZeroTurnaround and as you can imagine, we have to do quite a bit of instrumentation to get this nice reloading behaviour. Though as Murphy's law states, if something can go wrong it will and if something goes wrong after instrumentation then debugging it will not be a pleasant task. Which of course doesn't mean that it can't work nicely eventually, proven by our large number of happy customers.
Quasar's own documentation states that "If you forget to mark a method as suspendable ... you will encounter some strange errors. These will usually take the form of non-sensical ClassCastExceptions, NullPointerExceptions, or SuspendExecution being thrown". I think forgetting something is a very human thing to do and when you've got a large codebase then debugging such exceptions is what I meant by "adding complexity". But again this was only a speculation.
Regarding the other comment about shared mutable state, then of course it isn't necessarily required and I did write in the summary that "Java and the JVM provide enough tools to retrofit any concurrency model out there, but retrofitting anything won’t be the same as taking it into the initial design", which I do think still holds and I believe is one of the reasons why using libraries like Quasar won't be a trouble free experience, at least not until it's somewhat built into the JVM.
Though I won't even try to claim to know the ultimate truth and I'm always grateful to have someone correct me when I'm wrong. I appreciate your efforts in trying to make the JVM a better/more versatile platform with Quasar. I think that any such bold undertaking will only benefit the ecosystem in the long run.
Quasar's instrumentation is much less intrusive than JRebel's: no fields are added and no state changes tracked. There are only minor additions to the actual execution bytecode (again, no class-layout changes) that capture the stack. Those errors mentioned in the documentation (we should change that) are now automatically analyzed and tell you exactly where you've forgotten to annotate a method. Finally, with the changes in Java 9, instrumentation will become completely transparent, and require no manual annotation on the part of the user whatsoever.
> Java and the JVM provide enough tools to retrofit any concurrency model out there, but retrofitting anything won’t be the same as taking it into the initial design
The concurrency model requires no retrofitting. It is simply a strict superset of Erlang's. The computer and OS also support a full shared-memory concurrency model, yet it can be restricted -- not retrofitted -- to run languages like Erlang or Rust, with a more restricted model. Same goes for the JVM. It has a general-purpose shared heap, but any language may restrict its use. No retrofitting is required. Quasar doesn't impose any further restrictions (that's not its job -- simply to provide fibers), but a language like Clojure certainly does. Clojure is no less safer than Erlang. The implication is that an Erlang running on the JVM requires no C code to implement something like ETS, but the underlying JVM semantics are no more foreign to Erlang than the underlying machine semantics, and vice-versa: Erlang is no more foreign to the JVM than to the hardware. Erlang simply places restrictions on their use, and they both provide lower-level abstractions.
Mostly the comment about "adding complexity", comes from my own biased experience of working with bytecode instrumentation. I work on the JRebel team @ZeroTurnaround and as you can imagine, we have to do quite a bit of instrumentation to get this nice reloading behaviour. Though as Murphy's law states, if something can go wrong it will and if something goes wrong after instrumentation then debugging it will not be a pleasant task. Which of course doesn't mean that it can't work nicely eventually, proven by our large number of happy customers.
Quasar's own documentation states that "If you forget to mark a method as suspendable ... you will encounter some strange errors. These will usually take the form of non-sensical ClassCastExceptions, NullPointerExceptions, or SuspendExecution being thrown". I think forgetting something is a very human thing to do and when you've got a large codebase then debugging such exceptions is what I meant by "adding complexity". But again this was only a speculation.
Regarding the other comment about shared mutable state, then of course it isn't necessarily required and I did write in the summary that "Java and the JVM provide enough tools to retrofit any concurrency model out there, but retrofitting anything won’t be the same as taking it into the initial design", which I do think still holds and I believe is one of the reasons why using libraries like Quasar won't be a trouble free experience, at least not until it's somewhat built into the JVM.
Though I won't even try to claim to know the ultimate truth and I'm always grateful to have someone correct me when I'm wrong. I appreciate your efforts in trying to make the JVM a better/more versatile platform with Quasar. I think that any such bold undertaking will only benefit the ecosystem in the long run.