Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)  |  Nominations
JSRs: Java Specification Requests
JSR 356: JavaTM API for WebSocket

Stage Access Start Finish
Maintenance Release Download page 13 Aug, 2014  
Maintenance Review Ballot View results 29 Jul, 2014 04 Aug, 2014
Maintenance Draft Review Download page 24 Jun, 2014 24 Jul, 2014
Final Release Download page 22 May, 2013  
Final Approval Ballot View results 09 Apr, 2013 22 Apr, 2013
Proposed Final Draft Download page 13 Mar, 2013  
Public Review Ballot View results 22 Jan, 2013 04 Feb, 2013
Public Review Download page 21 Dec, 2012 21 Jan, 2013
Early Draft Review Download page 27 Sep, 2012 27 Oct, 2012
Expert Group Formation   06 Mar, 2012 12 Aug, 2012
JSR Review Ballot View results 21 Feb, 2012 05 Mar, 2012
JSR Review   07 Feb, 2012 20 Feb, 2012
Status: Maintenance
JCP version in use: 2.8
Java Specification Participation Agreement version in use: 2.0

The Java API for WebSocket JSR will define a standard API for creating WebSocket applications.

Expert Group Transparency:
  Public Communications
  Issue Tracking


Specification Leads
Star Spec Lead Danny Coward Oracle
Expert Group
  Arcand, Jean-Francois
: Jean-Francois Arcand
Caucho Technology, Inc
: Scott Ferguson
DRW Holdings, LLC
: Joe Walnes
  Fujitsu Limited
: Minehiko Iida
Google Inc.
: Wenbo Zhu
: Bill Wigger
  Lee, Justin
: Justin Lee
: Danny Coward
Red Hat
: Rémy Maucherat
  TmaxSoft, Inc.
: Moon Namkoong
: Mark Thomas
Voxeo Corporation
: Wei Chen
  Wilkins, Gregory John
: Greg Wilkins

Updates to the Original JSR

The following information has been updated from the original proposal on the dates shown.

Maintenance Lead:

Pavel Bucek
Oracle America, Inc.


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

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Oracle

Name of Contact Person: Danny Coward

E-Mail Address:

Telephone Number: +1 415 350 1701

Fax Number: +1 408 276 4185

Specification Lead: Danny Coward

E-Mail Address:

Telephone Number: +1 415 350 1701

Fax Number: +1 408 276 4185

Initial Expert Group Membership:


Supporting this JSR:


Section 2: Request

2.1 Please describe the proposed Specification:

This JSR will define a standard API for creating WebSocket applications.

There is a wide range of web applications that rely on timely updates from a central server like stock tickers, live maps, chat applications, collaborative online tools and multiplayer web-based games. WebSocket offers solution to the problems of latency, scalability and performance associated with HTTP based solutions like polling, long-polling and HTTP-streaming. There is a lot of interest in the Java developer community in creating web applications for the Java platform that utilize WebSocket. Given that the definition of WebSocket protocol is a proposed standard, and that the major web browsers either support, or plan to support it in their next major release, the time is right for a standard Java API for WebSocket.

This JSR will provide support in the Java EE platform for:-

  • Creating WebSocket Java components to handle bi-directional WebSocket conversations
  • Initiating and intercepting WebSocket events
  • Creation and consumption of WebSocket text and binary messages
  • The abililty to define WebSocket protocols and content models for an application
  • Configuration and management of WebSocket sessions, like timeouts, retries, cookies, connection pooling
  • Specification of how WebSocket application will work within the Java EE security model
This functionality will be a mix of APIs together with Java annotations to make for a flexible and easy to use programming model, as is found in other Java APIs in the Java EE platform.

The primary scenario is for that applications created using this technology be server based. That is to say, this technology will be for Java EE developers creating WebSocket applications in bi-directional commutation with browser clients. This is exemplified by a chat application, consisting of a web page, executing a client script that connects to a server application. The server application accepts new chat participants using the web sockets handshake, accepts incoming chat messages, broadcasts updates of the currently participating users to all clients in session, mediates client-to-client chat sessions.

A secondary scenario, is that this API will aid Java-clients of WebSocket applications residing on a server. This scenario is illustrated by a Java-based chat client participating in the chat example above.

This JSR will explore a separable client-API for WebSocket that will run standalone on Java SE (specifically including API support for initiating WebSocket communication) as part of its first release, or may defer this to a later release.

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

This specification is targeted for Java EE.

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.

This specification targets the Java EE 7 Platform. It will be based on the corresponding release of the Java SE platform.

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

No. Just the SE/EE Executive Committee.

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

The Java community has already seen the need to use WebSocket from Java applications, as can be seen from the list of projects that already provide a way to do so. The Java community is best served by one standard API for using WebSocket in an application.

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

Though WebSocket applications could be created by low level I/O APIs in Java SE, this approach is cumbersome and difficult. There is no standard Java API that is high enough level to make the creation of WebSocket applications simple.

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

Since WebSocket is TCP based, and uses an HTTP 'handshake' to initiate and terminate a WebSocket session, this project will likely build on existing networking and HTTP-based APIs where appropriate. This JSR will work closely with the Java Servlet 3.1 expert group who are exploring the integration of the intial handshake into the Java Servlet model.

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

Possibly:* or under

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


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


2.11 Are there any internationalization or localization issues?

This JSR will use the I18N support in Java SE.

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


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

We hope to deliver the final specification, reference implementation, and TCK in the Q1 of 2013. A rough schedule would be:

Apr 2012 Expert group formed
Q3 2012 Early Draft review
Q4 2012 Public Review
Q1 2013 Final release

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

The primary means of communication will be email, with conference calls and face-to-face meetings scheduled as needed. We will solicit feedback from the community and leverage the open source development model.

2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:

websocket-spec project site will be used to track all issues and disseminate information on the progress of the JSR. The Expert Group will conduct business on a publicly readable alias. A private alias will be used only for EG administrative matters, as needed.

- Is the schedule for the JSR publicly available, current, and updated regularly?

The schedule will be available on the project page for the JSR.

- Can the public read and/or write to a wiki for the JSR?

We'll use a public mailing list for comments.

- Is there a publicly accessible discussion board for the JSR that you read and respond to regularly?

We'll track such discussions and respond to them on the public comment mailing list.

- Have you spoken at conferences and events about the JSR recently?


- Are you using open-source processes for the development of the RI and/or the TCK?

Yes, the RI will be developed as a project.

- What are the Terms of Use required to use the collaboration tools you have prepared to use with the Expert Group, so that prospective EG members can judge whether they are compatible with the JSPA?

The terms will be available on the project page for the JSR.

- Does the Community tab for my JSR have links to and information about all public communication mechanisms and sites for the development of my JSR?

Yes, it will point to the project page for the JSR.

2.16 Please describe how the RI and TCK will de 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 RI will be delivered standalone and possibly bundled with some future release of Glassfish. The TCK will be delivered both standalone and as part of a suitable future release of the Java EE TCK. See the business terms for details.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 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).


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

Note that this information has been updated since this original proposal.

Specification license
Reference Implementation license
TCK license

2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

The Expert Group will conduct business on mailing list which is publicly readable.

2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

A JIRA issue tracker for websocket-spec project will be used for this purpose. The issue tracker URL is

2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

Expert Group's publicly readable mailing list will be archived at

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.

WebSocket Protocol Definition
Java Servlet 3.1

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

Will understand the current needs surrounding WebSocket usage and its implementations, and build an agreed API