Jetty WebSocket api vs the standard JSR 356 API

Question

Jetty 9 supports both it's own Jetty Websocket API as well as the standard JSR 356 API, for what I assume are historical reasons (Jetty's API precedes the final JSR 356).

I've looked over the basic documentation of both APIs, as well as some examples. Both APIs seem fairly complete and rather similar. However, I need to choose one over the other for a new project I'm writing, and I'd like to avoid using an API that might be deprecated in the future or might turn out to be less feature-rich.

So are there any important differences between the two except for the obvious fact that one is standardized?

Elbert

Answer 1

Implementor of both on Jetty here :)

The Jetty WebSocket API came first, and the JSR-356 API is built on top of it.

The JSR-356 API does a few things that the Jetty WebSocket API does not, such as

• Decoder's for automatic Bin/Text to Object conversion
• Encoder's for automatic Object to Bin/Text conversion
• Path Param handling (aka automatic URI Template to method param mapping)

However, the Jetty WebSocket API can do things the JSR-356 API cannot.

• WebSocketCreator logic for arbitrary creation of the WebSocket endpoint, with access to the HttpServletRequest
• Better control of timeouts
• Finer buffer / memory configurations
• You can manage WebSocket Extensions
• Supports Reg-ex based Path mappings for endpoints
• Access to raw Frame events
• WebSocket client supports HTTP proxies (JSR-356 standalone client has no configuration options for proxies)
• WebSocket client supports better connect logic with timeouts
• WebSocket client supports SSL/TLS (JSR-356 standalone client has no configuration options for SSL/TLS)
• Access to the both InetAddress endpoint information from the active WebSocket Session object
• Access to UpgradeRequest from active WebSocket Session object
• Better support for stateless endpoints
• Read events support suspend/resume logic to allow application some basic tcp backpressure / flow control
• Filter based or Servlet based configuration (the JSR-356 approach requires upgrade to occur before all other servlet and filter processing)

Hope this helps, if you want more details, please use the jetty-users mailing list, as this sort of question is really inappropriate for stackoverflow.

Introductory

Thanks for an excellent answer. I did notice a few of these differences (such as the encoders/decoders, and path parameter handling), but your answer is very helpful. I'm also not sure my question is entirely inappropriate here, although I do agree that it might feel more "at home" on your mailing list. After all, the question is not subjective, and falls well within the category of "a practical, answerable problem that is unique to software development" (stackoverflow.com/help/on-topic) – Elbert

It's been a while since this post, but if you don't mind my asking - what's wrong with being able to send pongs? – Bibliolatry