Will Continuations continue?

I spoke about dynamic language support and JSR292 at JavaOne today. I was quite disappointed that no one asked about continuations.

There are a variety of reasons why we haven’t implemented continuations in the JVM. High on the list: continuations are costly to implement, and they might reek havoc with Java SE security model. These arguments are pragmatic and a tad unsatisfying. If a feature is really important, shouldn’t we just bite the bullet?

I’ve thought about this a bit, and here’s my take on why we really shouldn’t add continuations to the JVM. It’s bound to stir up controversy and annoy people, which is a good reason to post it. By far he most compelling use case for continuations are continuation-based web servers.

A couple of weeks ago I was embroiled in a rather passionate argument about the relevance of continuation-based web servers at an academic retreat at Dagstuhl, Germany. This is an opportunity for me to write down my thoughts on that topic, as the two are closely linked.

The use case for coninuation-based web servers is simple. I want to book a hotel via the web. The web server asks: where? I say Alaska. I love polar bear rides. The server shows me a list of hotels in Alaska. I pick one, it shows me the details. I decide that maybe Alaska in December is too cold, so I clone the browser window, press back a couple of times, until I’m back to the question: where do you want to go today? This time I answer: Hawaii. I get a list of hotels in Hawaii, and pick one. Now I can compare the two destinations side by side.

Upon reflection, I decide to go to Alaska after all. When will I ever get a chance to go Polar Bear Back riding again? I press the button that says “Book hotel and tickets Now!”. I go to the airport on the designated day. As I walk off the plane into the Honolulu sunshine, I find that my parka is uncomfortably warm.

What happened? The server booked my hotel and tickets, based on the last page I visited - which, as far as it knows, was the Hawaii hotel page. It knows nothing of cloned browser windows and back buttons. When I started asking about Hawaii, it literally forgot about Alaska.

The reason the servers tend to forget in this way is because they only keep one call stack per session. This in turn stems from the fact that HTTP and web browsers were designed for browsing stateless hypertext documents, not for dealing with stateful applications.

Continuations can help here, because they can give us handles for multiple stacks, and allow us to return to different ones at will. This is wonderful, but it’s important to realize that this use case only matters if you’ve designed your UI to follow the he-said/she-said style typical of traditional web apps designed around HTML. This UI is a regression to the days of time sharing, before the advent of the personal computer and GUIs. It’s forced upon you by HTTP; you’d never design a true GUI application to behave this way.

The other important point is that the future of web apps is going to be different. Ajax is a sign of things to come (though it’s only a symptom, not a real solution - but that is another story). In time, entire applications will be downloaded and provide a full GUI in the context of a single page. The primitive dialog we see today will return to the ash heap of history where it belongs.

Such an application would use a modern GUI to open multiple windows on multiple hotels. It would maintain the state that the server “forgot” in our example in objects in the heap. Rather than relying on the server’s stack to keep track of what location we’re looking at, the window showing us the Alaska hotel will be a view on a model object that represents the hotel being viewed. When you pressed “Buy”, it would pass all the information necessary to complete the transaction onto the server. Consequently, we’ll have no more of a pressing need for continuations than traditional applications have today.

Summary: In the short term, continuation based web servers are very nice. Seaside is the nicest one I’ve seen. But ultimately they are just a phase, and we can already see how we will outgrow that phase. Since continuation-based servers won’t be all that significant in the long term, and given the huge lead times and costs of adding continuations to the JVM, it makes little sense to support them.


Post a Comment:
Comments are closed for this entry.



« June 2016