Skip to main content

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

  • From: Danny Coward < >
  • To:
  • Cc: Justin Lee < >
  • Subject: [jsr356-experts] Re: Some API suggestions from EDR
  • Date: Thu, 25 Oct 2012 14:56:47 -0700

Thanks Justin - see inline
" type="cite">

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.
" type="cite">
 

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

" type="cite">

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