JSR Continuations Provider API - RIFE/Continuations

Work in progress

This is the work-in-process draft of what will be submitted to the JCP as the JSR for the Continuations Provider API.

Title:

Continuations Provider API

Summary:

The purpose of this specification is to standardize an API to provide continuations functionalities for the Java programming language.

Section 1: Identification

JCP Member submitting this proposal: Geert Bevin

Name of Contact Person: Geert Bevin
E-Mail Address: gbevin@uwyn.com
Telephone Number: +3264848003
Fax Number: +3264848003
Name of Specification Lead: Geert Bevin
E-Mail Address: gbevin@uwyn.com
Telephone Number: +3264848003
Fax Number: +3264848003

Initial Group Membership:
Geert Bevin (RIFE)
Torsten Curdt (Commons/JavaFlow)
Patrick Lightbody (WebWork, Struts 2)
Joe Walker (DWR)
Alexandru Popescu (TestNG, InfoQ, WebWork)
Jonas Bonér (Open Terracotta, AspectWerkz, Eclipse AspectJ, backport175)

Supporting this JSR:
Hani Suleiman
Apache

Section 2: Request

2.1 Please describe the proposed Specification:

Continuations have been available in programming languages for decades, but they recently received a lot more interest when used for the development of complex web application flows. Continuations allow capturing the local variable stack, the method call stack and the program location. Bundled together, this represents the execution state of a program, which can be restored and resumed at a later time.

The novelty in the recent usage is the concept of partial continuations. This allows the execution state to only be captured from an entry point onwards, for example the execution of a server-side action. The previous state is discarded, for example the state of the servlet container. At a later time, a partial continuation can be retrieved and resumed inside the context of another execution thread, providing that the entry point remains the same.

The Java programming language lacks the capability to sufficiently capture the execution state of a program. This specification aims to standardize and API that makes it possible to:

demarcate an entry point for partial continuations
obtain the local variable stack
obtain the method execution stack
obtain the exact location inside the currently executing method

This data will be bundled inside a continuation class with at least the following capabilities:

retrieve the unique identifier of a continuation
invalidate a continuation
retrieve a continuation's local variable stack
retrieve a continuation's method execution stack
retrieve a continuation's program location

Since continuations are snapshots in time, they are structured in a tree where the root is the first continuation that was executed by a particular user. This specification will therefore also at least standardize the following behavior of the continuation class:

retrieve its parent continuation
invalidate an entire continuation tree
create a new blank continuation from an existing continuation

To allow the execution to be resumed, continuations need to be maintained inside a manager that is able to retrieve them based on their unique identifiers. This specification will also at least standardize the following behavior of the manager:

store a new continuation inside a manager
retrieve an existing continuation using its unique identifier
removal a existing continuation using its unique identifier

The expert group will also evaluate other capabilities like:

storage and retrieval of continuations outside of live memory
automatic invalidation and purging of outdated continuations
layered stacks of continuations where one calls another and is able to retrieve an answer from the second
step-back continuations to return to earlier execution steps

Using these functionalities, developers are able to provide targeted continuations behavior for their tools, libraries and frameworks.

The expert group also will decide upon how to address new issues that can arise when solutions implement the continuations provider API, like:

possible multiple or non execution of the finally statement
possible multiple release of synchronization semaphores
possible injection of new values to replace final variables
investigation of class versioning solutions for when continuations are resumed in contexts with newer class signatures

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java Standard Edition

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

The target platform is Java Standard Edition 5 with additional capabilities for Java SE 6.

2.4 Should this JSR be voted on by both Executive Committees?

No.

2.5 What need of the Java community will be addressed by the proposed specification?

This specification will allow the Java community to benefit from the additional programming capabilities that continuations offer them.

For example:

the creating of complex web application flow in the Java programming language without any external state declarations
discrete event-driven systems that suspend the execution and resume when events occur, instead of a constant polling model
request thread parking for Ajax web applications to free up servlet container sockets while a long-running computation is running, instead of Ajax polling
multi-threaded test scenarios where several executions can be suspended with a well known state and resumed at the same time

2.6 Why isn't this need met by existing specifications?

None of the existing specifications provide this functionality, nor does the Java programming language.

2.7 Please give a short description of the underlying technology or technologies:

The continuations provider can be implemented in a variety of ways, from byte-code modification through class-loaders or agents, to regular thread suspension or a layer on top of the current virtual machine that adds additional capabilities. Each implementation has its benefits and drawbacks.

2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

We propose to make this a standard extension under the javax.continuations package name.

2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No. The specification will be general purpose, pure Java and solely relying on the JSE specification.

2.10 Are there any security issues that cannot be addressed by the current security model?

No.

2.11 Are there any internationalization or localization issues?

No. There are no functionalities that relate to internationalization or localization.

2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No. There are no existing specifications that provide a solution for this problem area.

2.13 Please describe the anticipated schedule for the development of this specification:

The following dates are preliminary:

Expert Group Formation: February 2007
Early Draft Review: August 2007
Public Review: March 2008
Final Release: September 2008

2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.:

The Expert Group will use java.net for email communication over the mailing list. The specification will be collaboratively written using a wiki and Subversion will be used for the development of the reference implementation. Since several open-source projects need the functionalities of this specification, a lot of the work will be performed in an open-source fashion during the development on the RI.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

The expert group will function in an open-source community fashion with public mailing lists. Regular snapshots of the RI and the associated specification and documentation will be published so that real-world feedback on the effort can be solicited as early as possible.

2.16 Please describe how the RI and TCK will be delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.:

The RIFE project, most notable RIFE/Continuations will deliver the RI and TCK as a standalone library that can be integrated into other solutions. It will target Java SE 5 and 6 with additional capabilities for the later versions. The current project state is just a starting point and the RI implementation will implement the API that results out of the specification.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.16 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).:

N/A

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.:

The Specification, RI and TCK will be licensed under a free-of-charge open source license that is compatible with the Java SE and Java EE license, most probably the Apache 2 license.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Descriptions and documentation

General definition of continuations - http://en.wikipedia.org/wiki/Continuation
Web continuations overview - http://rifers.org/wiki/display/RIFE/Web+continuations
Struts continuations - http://cwiki.apache.org/WW/continuations.html
Webwork continuations - http://www.opensymphony.com/webwork/wikidocs/Continuations.html
Continuations for Curmudgeons - http://www.intertwingly.net/blog/2005/04/13/Continuations-for-Curmudgeons
Movie of regular Java debugger analyzing a web execution flow - http://rifers.org/theater/demo4_stepbackcontinuations_debugging

Proprietary implementations

RIFE/Continuations project - http://rifers.org/wiki/display/RIFECNT/Home
Apache Commons/Javaflow - http://jakarta.apache.org/commons/sandbox/javaflow/
Dalma Workflow Engine - https://dalma.dev.java.net
The Jau Virtual Machine - http://jauvm.blogspot.com/
Brakes, thread serialization - http://www.cs.kuleuven.ac.be/~eddy/BRAKES/brakes.html
Jetty 6 continuations - http://docs.codehaus.org/display/JETTY/Continuations

Existing communities

Continuation unification effort at Codehaus - http://archive.continuation.codehaus.org/dev

3.2 Explanation of how these items might be used as a starting point for the work.

The RIFE/Continuations project is already underway as an extraction of the web continuations functionality of the RIFE Web Application Framework itself. It has as such already been adopted by the Struts and Webwork Frameworks. It demonstrates the viability of an implementation and the interest of the community. The real-world experience that has been gathered from implementing the RIFE/Continuations project will be very valuable for the design of a standard Continuations Provider API.