Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] JSR-356 Design Thought
I saw in the javadoc what methods are allowed and not allowed, but if by "accident" someone adds a param to an annotated method, it will compile fine, but then be broken. Or I loose the code hinting capabilities of my IDE. I like annotations, but It depends how they are used. Glad to hear I am not alone in thinking the trend is unfortunate.




On Tue, Feb 18, 2014 at 1:49 PM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:

On Mon, Feb 17, 2014 at 10:10 PM, Mack Gerhardt <mack@xxxxxxxxxxxxxx> wrote:
Is it me or does anyone else feel like the annotation based setup of a WebSocket pojo is like trying to bring dynamic feel of node and python to java. Why not have concrete interfaces to implement vs methods to annotate, and if you screw up the signature it doesn't work as intended vs implementing an interface and knowing at compile time, and having code hinting in any ide.

The javadoc for the annotations somewhat spells out what you can and can't do.

let me see if I can clarify this a bit...

@OnMessage

  parameter choices (order of parameters is irrelevant):
So for @OnMessage you can see the following valid method declarations:

// first some basic ones
void onmessage(String msg)
void onmessage(Session session, String msg)
void onmessage(String msg, Session session)
void onmessage(byte data[])
void onmessage(ByteBuffer data)

// here some examples of partial message support
void onmessage(String partial, boolean isLast)
void onmessage(Session session, ByteBuffer buf, boolean isLast)

// heres some Decoder based ones
void onmessage(MyData data) // assumes a MyDataDecoder that implements a Decoder type
void onmessage(Session session, int value) // part of the JSR spec, and will convert a text message (eg: "123") to an int
void onmessage(boolean value) // part of JSR spec, will convert text message (eg:"true") to a boolean

// also, here's the return type behavior - returned information will be sent automatically to remote endpoint
String onmessage(String msg) 
byte[] onmessage(ByteBuffer buf)

// heres some @PathParam setup
void onmessage(ByteBuffer data, @PathParam("gameid") int gameId)

// heres a really complex one, using as many features as possible
ByteBuffer onmessage(MyGameAction action, Session session, @PathParam("channel") String channel, @Pathparam("gameid") int gameId, @PathParam("spectator") boolean spectator) 

Once you start to see the multitude of options, you quickly start to realize what the JSR is attempting to do.
The return types + @PathParam features are just not present on the extends Endpoint style of use.
However, you CAN use the Decoders with the extends Endpoint usage.

The JSR-356 spec (as it currently stands) is incomplete, poorly defined, with many vague behaviors (just wait till you get into the Configurators).
It has to undergo a revision for any long term success, but so far, there's been little movement in that regard.

Since WebSocket (the protocol / RFC-6455) was declared as a message based protocol, not streaming, the various APIs started to fall into line to notify based on messages.  If the protocol was streaming based, the APIs would look radically different (or nothing new at all, but merely use URLSocketConnection or something similar).

 

One of the things I love about java is the rigidity, and that it is not dynamic, and I can reflect over  classes, and methods. It just feels like they are trying to do cool things with jsr-356, instead of a nice clean api.


This is the trend, unfortunately.
Annotate everything, bind nothing in code, let the runtime figure it out.

- Joakim


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users


Back to the top