This proposal has been approved and the Jakarta WebSocket project has been created.
Visit the project page for the latest information and development.

Eclipse Project for WebSocket

Monday, November 13, 2017 - 11:47 by Dmitry Kornilov
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State

This project is created as part of the process of transitioning Oracle Java EE 8 and GlassFish technologies to the Eclipse Foundation as described in The Eclipse Enterprise for Java Project Top Level Project Charter (


Eclipse Project for WebSocket provides the API and TCK for Java API for WebSocket, starting from the specification defined by JSR-356.

An implementation for the WebSocket API is part of the Eclipse Tyrus project proposal.


Java API for WebSocket (JSR-356), specifies the API that Java developers can use when they want to integrate WebSockets into their applications - both on the server side as well as on the Java client side.

Why Here?

The top level EE4J project was created consistent with the direction described in The Eclipse Enterprise for Java Project Top Level Project Charter (   This project is created under the top level EE4J project as one of Oracle Java EE 8 and GlassFish technologies being transitioned to the Eclipse Foundation.

Initial Contribution

Eclipse Project for WebSocket API repository from

Source Repository Type

How was the initial committer list formed? There doesn't seem to be much overlap with the JSR 356 Expert Group. Given the close relationship between the API and the specification, I'd expect to see more EG members on the initial committer list.

I have an question that recently came up involving how the implementation of a function in the websocket spec.

In section 4.1.2 the websocket specification says:

"The implementation must attempt to encode application objects of matching parametrized type as the encoder when they are attempted to be sent using the RemoteEndpoint API [WSC-4.1.2-1]."

Does "matching" mean a direct match of class objects, or any match which can be assigned as a direct or extension or interface implementation?

The issue with direct, is that it is limiting, and excludes therefore using interfaces as the encoder/decoder parameterized type.

The issue with allowing extensions or interfaces is that it introduces ambiguities that the specification does not address.  For example, if

two encoders implement two different interfaces and both are specified as valid encoders for an Endpoint, what should be done in the case

that an object to encode is to sent where said object implements both interfaces?  Is the correct encoder basically a random selection between

the two possible encoders?

In reply to by Bill Wigger

This is clearly one to clarify in the first iteration of the WebSocket spec at Eclipse once we reach that point. That said, my current thinking is set out below.

Given that 4.2.2 uses the phrase "the first appropriate Decoder in the list" then that suggests to me that there may be more than one appropriate Decoder. Therefore the test needs use Class#isAssignableFrom(Class).

Section 4.2.2 also says "first" so that clarifies which Decoder to use if there are multiple matches.

On the basis that encoding and decoding should be symmetical, and that client and sever endpoints should default to the same behaviour, I would expand the langauge from 4.2.2 to cover Encoders and Decoders for both client and server enpoints.