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 …
Context & Ripple Effects
This lands five months after Business Week's "Java? It's So Nineties" jab framed the platform as aging, which is exactly the pressure the speaker was addressing on stage: a JavaOne session built around dynamic language support and JSR292, the effort to make the JVM a comfortable home for non-Java languages.
The telling detail is negative space — nobody in the audience asked about continuations, and the speaker volunteered why they're absent anyway: JVM developers cite a variety of reasons for not implementing them. A feature request surfacing only from the maintainer side, not user demand, says something about where the energy in JVM evolution actually sits.
First-order effects
- Language implementers targeting the JVM have their answer: continuations will not be there to build on, so anything continuation-dependent has to be emulated with threads or abandoned.
Second-order effects
- JSR292's dynamic-invocation work becomes the de facto priority path for getting scripting languages onto the JVM, concentrating Sun's VM engineering budget on call semantics rather than control-flow features like continuations.
Third-order effects
- If the pattern holds, the JVM's roadmap is set by what alternative languages need rather than by Java itself — pushing the platform toward becoming a general-purpose multi-language runtime, and leaving any ecosystem that genuinely requires continuations to look elsewhere.
The trend: The JVM is evolving into a polyglot runtime whose feature decisions are driven by dynamic-language demands, with Java-the-language ceding its position as the sole design center.