Hi Pavel: Thanks for your input. You guys are a lot smarter than I am so I won't pretend to have a situation you haven't thought about.
My typical use case is to fetch database data from the server using ejb. I return the data in serialized java objects to my JavaFX clients (websockets are not just for browsers though few seem to realize that!). There is never a way to tell how much data may be returned. It may be from a job costing system that returns thousands of rows. I like the idea of using websockets rather than a direct ejb connection because I want, in the future, to add server pushes to my application. i.e. if some user adds a ledger account all registered GL listeners would get the new account in their desktop. Neither ejb nor rmi provides that capability. In fact, nothing else does except websockets as far as I know. I'm sure I can learn to use the new .request(long) feature. Looking, as you mentioned, at the Flow api I see where they used the UnboundedSubscription with request(Long.MAX_VALUE) which was my initial reaction to this new wrinkle. I am under the impression that this new API requires the developer to buffer the messages until all the data is complete. As I recall (it's been a few months since I implemented) decoders handled that in the old API and if I am correct that is going to put a lot more work on the plate of developers. If my understanding is correct I'd suggest listeners should do the buffering and deliver a complete message. If it's written once in the implementation it would save thousands of developer hours recreating the same wheel. At least this approach makes sense in my use case. Partial pieces of serialized objects are useless. Can you expound a little more on this: "Finally, each of the listener's methods asks the user to signal when the user has processed the message it bears [2]." All I see is that the method returns a CompletionStage which triggers a procession of CompletionStage objects (not sure yet how this ends except by returning a null?) and I don't see in the docs how this signals the listener except that the method exits and may be called again. I'm sorry to be so dense here. Finally, is there a target release to graduate from incubator? I'm kinda stuck until the dust settles. May it hit jdk10 or 11? "Incubating Feature. Will be removed in a future release." sounds so.....ominous! Again, Pavel, thanks for your response and interest.
