Hi Joakim,
thanks for your feedback!
On 21/05/14 20:51, Joakim Erdfelt wrote:
> Some conflicting statements in 2 different locations...
>
> The proposed additional text for the existing
> Session.addMessageHandler(MessageHandler) makes the statement that the
> existing method is
> "not safe to use unless you are providing an anonymous class derived
> directly from javax.websocket.MessageHandler.Whole or
> javax.websocket.MessageHandler.Partial."
> Which clearly gives the exceptions to the safe/unsafe nature of its use.
> https://github.com/pavelbucek/websocket-spec/pull/1/files#diff-236cdd0a575a0ad4890bc01ab8754e9bR90
>
> Yet, the text in spec/chapters/applications.tex says its "not safe for
> use in all circumstances", without the extra exceptions listed.
> https://github.com/pavelbucek/websocket-spec/pull/1/files#diff-d2375fd850384efcdd9383403a7d9587R37
The exception(s) is mentioned in the very next sentence: "The only case
where you can safely use this method is when you are directly
implementing \textbf{MessageHandler.Whole} or
\textbf{MessageHandler.Partial} as an anonymous class."
By adding this "exception" I wanted to express that users of the
original API do not have to necessarily change existing code. Generally,
the original method should not be used - it is not really guaranteed
that it will work in the future (and here I mean very distant,
hypothetical future). Current exception is relatively reliable because
compiler stores the generic type information into generated class files
to have the ability to perform type checking. Imagine the compiler which
will store this information somewhere else - then this info won't be
available via current reflection API and even the mentioned "exception"
won't work. (Note: I don't know of any compiler which works that way nor
about any plans to do so).
Maybe that shed some light and explained why the current wording may
seems little bit harsh - we want to encourage use of the newly
introduced methods..
I noticed your comment on github - can we please keep the discussion here?
Thanks,
Pavel
>
>
>
> --
> Joakim Erdfelt <joakim_at_intalio.com <mailto:joakim_at_intalio.com>>
> webtide.com <http://www.webtide.com/> - intalio.com/jetty
> <http://intalio.com/jetty>
> Expert advice, services and support from from the Jetty & CometD experts
> eclipse.org/jetty <http://eclipse.org/jetty/> - cometd.org
> <http://cometd.org/>
>
>
> On Wed, May 21, 2014 at 11:18 AM, Jeanfrancois Arcand
> <jfarcand.oss_at_gmail.com <mailto:jfarcand.oss_at_gmail.com>> wrote:
>
> Pavel,
>
> can you redo the diff that *only* include relevant change? I think
> it worth for all of us to just see what is really changed.
>
> Thanks
>
> -- Jeanfrancois
>
> On 2014-05-21, 1:49 PM, Pavel Bucek wrote:
>
>
> Please provide any feedback by COB Friday - 5/30/2014. We plan
> to send this to JCP in the first week of June to start the 30
> day review period for this MR.
>
> Thanks,
> Pavel
>
> On 21/05/14 11:22, Pavel Bucek wrote:
>
> Hi all,
>
> as you might have noticed, I filed blocker bug against
> WEBSOCKET_SPEC project - [1].
>
> The main issue is that current Session.addMessageHandler
> method cannot handle message handlers in form of lambda
> expressions, because there is no information about its
> generic type parameter available. We discussed this issue
> with Brian Goetz and he pointed out that current API is
> wrong not only for this case, but also for more
> complicated generics usages and is reliable only for
> anonymous classes created directly from
> MessageHandler.Whole and MessageHandler.Partial (type
> information is in the generated class file), so the issue
> itself is not limited only to Java SE 8.
>
> We think that this issue is important enough to fix it in
> a Maintenance Release as soon as possible, not tied to
> Java EE 8 planning or anything else.
>
> Proposed solution is to add two additional
> Session.addMessageHandler methods with explicit type
> information, please see [2] for more complete description.
> I also attached updated version of the specification
> document. There is only one addition - last paragraph in
> chapter 2.1.3 "Receiving Messages" and the sample code in
> chapter 2.1.4 "Sending Messages" was modified to use the
> newly introduced addMessageHandler method with explicit type.
>
> Complete change diff can be seen here [3] (but it contains
> lots of noise - spec licence etc; changes.txt should be
> good enough for evaluation).
>
> Any feedback would be greatly appreciated!
>
> Thanks and regards,
> Pavel
>
> [1]: https://java.net/jira/browse/WEBSOCKET_SPEC-226
> [2]:
> https://github.com/pavelbucek/websocket-spec/blob/WEBSOCKET_SPEC-226/websocket-1.1-changes.txt
> [3]: https://github.com/pavelbucek/websocket-spec/pull/1/files
>
>
>
>