Fables of the Reconstruction Part 1: Losing the Thread
It’s a wonderful time to be a Scala programmer. The language is maturing, its community is growing more diverse, and more of its use is professional. Also and not coincidentally, there are more overheated debates about its legitimacy to wallow in than ever before. Everybody is having a ball.
I’ve been reflecting on my first Scala library, Dispatch, and decided it was time to start the move to a new underlying client library. The HttpComponents library has served us honorably over the years. But lately it seems our paths have diverged.
~~~
Two years ago I finally understood that thread-blocking I/O just does not cut it, and never did. Java had originally bet the farm on threads. Much like the language’s rigid embrace of OOP left no room in its heart for the most basic functional constructs, its commitment to threading squeezed out tried and true models like the event loop. The idea was to dampen the learning curve, and it worked: you only had to learn a few concepts like classes, objects, and threads to get started in Java.
The high computational cost of blocking I/O might have been worth it if the resulting abstractions were improvements over the alternatives. But for all but the most trivial examples, working with those deceptively simple concepts incurs a heavy complexity cost in your own code. Blocking calls must be threaded, and threads must be synchronized, and before you know it you have implemented your own mind boggling concurrency model, rather badly.
Slowly and wisely much of the Java community has migrated to standardized models for concurrency like futures and thread-pool executors, thereby avoiding the horror of deadlocks—but not exactly burning down the house with I/O performance. And looking around, those models are fairly similar to the abstractions also used on top of non-blocking I/O.
After all that fuss, everyone is riding bicycles but ours aren’t as smart.
To be sure, New I/O has been available in Java for a very long while (since 1.4) and smarter people than me have been harnessing it since that release. But I am talking about the mainstream of Java and particularly the mainstream of Scala. I am talking about the answer to the question, “What’s the Scala way of sending an HTTP request to a server?” Whether or not the answer has involved bijective maps and symbolic method names, it has usually involved blocking I/O. And that’s a real problem.
My original plan to reconcile Dispatch with this reality was to offer an experimental module based on HttpComponent’s NIO client and slowly phase out the traditional module.
But when I began this effort there was only an alpha release of the Apache NIO client, and the differences between it and the blocking client were substantial, so that it wasn’t nearly as easy as I had hoped to build a core module with separate wrapping modules for the different clients. The Dispatch NIO module that came out of this attempt didn’t feel right. It didn’t feel better than the blocking I/O module, it just felt weirder.
A few months later I tried to upgrade to a newer beta version of the NIO client only to find that its design had been significantly changed, and probably improved—but it broke enough of my code to cause me to reassess the landscape. HttpComponents was struggling to fit New I/O interaction into their sprawling Old I/O framework, maintaining backwards compatibility but still providing some degree of conceptual unity. For their user base they were fighting the good fight, but I realized it was not my fight.
Life in software is too short to carry anyone else’s baggage.
Stay tuned for Part 2: Have you tried rebooting it?
