Skip to main content

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

  • From: Justin Lee < >
  • To:
  • Subject: [jsr356-experts] Re: Some API suggestions from EDR
  • 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 < " target="_blank"> > 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

--
Danny Coward
Java EE
Oracle Corporation



--



--
Danny Coward
Java EE
Oracle Corporation



--



[jsr356-experts] Some API suggestions from EDR

Danny Coward 10/25/2012

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

Justin Lee 10/25/2012

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

Danny Coward 10/25/2012

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

Justin Lee 10/25/2012

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

Scott Ferguson 10/25/2012
 
 
Close
loading
Please Confirm
Close