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).<

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.