If we start from the assumption that Loom is the future (the first step
may actually be to debate that assumption)....
So let's start with that debate.
I'm a self confessed Loom sceptic.
I do understand that async code is difficult and mostly full of bugs. I do understand the desire to just write blocking code. I also think that the vast majority of applications written really don't care one way or the other. So I get why Loom is attractive.
But what nobody has been able to tell me, is why it will be different this time around? The approach has been tried before with Green threads and Solaris multitasking and ultimately failed, as described in
this paper from 2002 on Multithreading in Solaris. I cannot see in Loom any innovations that will generally solve the problems of m:n scheduling outlined in that paper.
Thus I consider that Loom is at best a better implementation of Green threads with really good integration into the JVM and its libraries. This is not a bad thing and will probably be an excellent solution for the vast majority of applications, for which the benefits of simple blocking code will far outweigh any downsides with striving for the ultimate scheduling efficiencies.
So, if we were talking about designing a new general purpose application API, then I think a blocking only approach that depends on Loom for scale would be viable for the vast majority of use-cases.
But we are not talking about an application API. The proposal being discussed here is for a low level HTTP API: just the minimum to get HTTP messages efficiently received and sent, that can be used as the basis for various application frameworks and/or very specific direct usages. To put all our eggs in the Loom basket for such an API would be to make the bet that Loom will be sufficient and optimal for not just most, but all HTTP usages in java. I don't think that Loom can claim to be that general of a solution.
Thus I advocate that any new low level HTTP API should be asynchronous only with the aim being the simplest API to send/receive HTTP messages in java using current best practices of the language. The design should allow for both simple implementations and optimized implementations (e.g supporting memory mapped files, gather writes, etc.). Application APIs can be layered on top and they may be blocking and dependent on Loom if they wish. Note that implementing a blocking Loom application API on top of an async HTTP API is trivial, whilst the opposite is impossible (mmm maybe pointless is a better word).
cheers
