jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: Some API suggestions from EDR

From: Justin Lee <jlee_at_antwerkz.com>
Date: Thu, 25 Oct 2012 18:37:03 -0400

I'm clearly missing something here. How exactly would we be able to tell
what they implemented? Because this test won't even compile:

public class Handler {
public interface MessageHandler<T> { }

public static void main(String[] args) throws Exception {
MessageHandler<String> handler = new MessageHandler<String>() {};

System.out.println(handler instanceof MessageHandler<String>);
}
}

So when a frame comes in, how are we going to decide which callback to call?

On Thu, Oct 25, 2012 at 5:56 PM, Danny Coward <danny.coward_at_oracle.com>wrote:

> Thanks Justin - see inline
>
>
>> A) Consolidate MessageHandlers (Issue
>>
>> Currently we have MessageHandler.Text, MessageHandler.Binary,
>> MessageHandler.AsyncText, MessageHandler.AsyncBinary,
>> MessageHandler.BinaryStream, MessageHandler.CharStream,
>> MessageHandler.DecodedObject and MessageHandler.Pong.
>>
>> The same functionality could be consolidated into two handler interfaces
>> instead, for example:
>>
>> MessageHandler<T>
>> void onMessage(T message)
>>
>> with allowable types T of String, ByteBuffer, InputStream, Reader,
>> Object, and a new interface PongMessage, and
>>
>> AsyncMessageHandler<T>
>> void onMessage(T partialMessage, boolean isLast)
>>
>> with allowable types String, ByteBuffer.
>>
>> IMO: Some type of consolidation seems cleaner to me, and also a little
>> simpler to extend to other types in the future.
>>
>
> Internally, how will implementations be able to tell which callback to
> call when a frame arrives if instanceof is no longer an option? I'm sure
> I'm missing something here with this change but it feels like we're losing
> something with this change.
>
> I don't think any information is getting lost in the change: If they
> implement MessageHandler<ByteBuffer> we know they want a ByteBuffer, if
> they implement MessageHandler<String> we know they want a string, if they
> implement MessageHandler<InputStream> etc. If they implement just
> MessageHandler<Object> we know we need to find an appropriate encoder.
>
>
>
> 4. Methods in public interfaces do not themselves need to be declared
> public. (style issue / choice)
>
> IMO: Will defer to majority here, but I prefer public declaration.
> Oracle (née Sun) style guides recommend leaving off the modifiers as
> they're redundant.
>
> My preference stands corrected ! I propose to leave them off.
>
> - Danny
>
>
>
> 5. Endpoint
>> Parameter ordering is inconsistent
>> onClose(Session, CloseReason) vs. onError(Throwable, Session)
>> Parameter naming is inconsistent s vs. session
>>
>> IMO: Will make consistent, Session as last parameter unless I hear
>> otherwise.
>>
>> 6. Generics
>> API uses raw types in a few places.
>>
>> IMO: Will fix unless I hear otherwise.
>>
>> 7. Session
>> s/getRemoteL/getRemote/
>>
>> IMO: oops, will fix unless I hear otherwise.
>>
>> Thanks,
>>
>> - Danny
>> --
>> <http://www.oracle.com> * Danny Coward *
>> Java EE
>> Oracle Corporation
>>
>
>
>
> --
> You can find me on the net at:
> http://antwerkz.com http://antwerkz.com/+
> http://antwerkz.com/twitter http://antwerkz.com/github
>
>
>
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>



-- 
You can find me on the net at:
http://antwerkz.com             http://antwerkz.com/+
http://antwerkz.com/twitter   http://antwerkz.com/github