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
--
Joakim Erdfelt <joakim_at_intalio.com>
webtide.com <http://www.webtide.com/> - intalio.com/jetty
Expert advice, services and support from from the Jetty & CometD experts
eclipse.org/jetty - cometd.org
On Wed, May 21, 2014 at 11:18 AM, Jeanfrancois Arcand <
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
>>>
>>
>>
>