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 (https://projects.eclipse.org/projects/ee4j/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.
The top level EE4J project was created consistent with the direction described in The Eclipse Enterprise for Java Project Top Level Project Charter (https://projects.eclipse.org/projects/ee4j/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.
Comments Sign in to post comments
Initial committer list
Submitted by Mark Thomas on Tue, 2017-11-21 15:27
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.
Re: Initial committer list
Submitted by Remy Maucherat on Fri, 2017-11-24 08:49
+1
Encoder Type Matching - direct or assignable?
Submitted by Bill Wigger on Fri, 2017-12-01 10:53
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?
Re: Encoder Type Matching - direct or assignable?
Submitted by Mark Thomas on Wed, 2017-12-13 15:22
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.
Mark