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 <[email protected]> wrote: > > On Mon, Feb 17, 2014 at 10:10 PM, Mack Gerhardt <[email protected]>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... > > http://docs.oracle.com/javaee/7/api/javax/websocket/OnMessage.html > @OnMessage > > parameter choices (order of parameters is irrelevant): > > - javax.websocket.Session (optional: [0..1]) > http://docs.oracle.com/javaee/7/api/javax/websocket/Session.html > - *Basic Websocket Message Type (required: [1] only)* > - *TEXT* > - *Whole Message Delivery (pick 1)* > - java.lang.String > - or any javax.websocket.Decoder.Text you have provided > > > http://docs.oracle.com/javaee/7/api/javax/websocket/Decoder.Text.html > - *Partial Message Delivery (both must be specified)* > - java.lang.String > - boolean isLast > - *Streaming Delivery (pick 1)* > - java.io.Reader > - or any javax.websocket.Decoder.TextStream you have provided > > > http://docs.oracle.com/javaee/7/api/javax/websocket/Decoder.TextStream.html > - *BINARY* > - *Whole Message Delivery (pick 1)* > - byte[] > - java.nio.ByteBuffer > - or any javxx.websocket.Decoder.Binary you have provided > > > http://docs.oracle.com/javaee/7/api/javax/websocket/Decoder.Binary.html > - *Partial Message Delivery (boolean plus only 1 data type)* > - byte[] > - java.nio.ByteBuffer > - boolean isLast > - *Streaming Delivery (pick 1)* > - java.io.InputStream > - or any javax.websocket.Decoder.BinaryStream you have > provided > > > http://docs.oracle.com/javaee/7/api/javax/websocket/Decoder.BinaryStream.html > - *PING/PONG* > - javax.websocket.PongMessage (required) > > http://docs.oracle.com/javaee/7/api/javax/websocket/PongMessage.html > - PathParam parameters (optional: [0..n] entries) > - This can consist of any java primitives that are also annotated > with the @PathParam annotation to indicate what part of the upgrade > path is > to be reported to the @OnMessage event. > > 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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
