[jax-rs-spec users] Server-Sent Events API proposal

From: Pavel Bucek <>
Date: Tue, 24 Jan 2017 20:54:38 +0100

Dear experts,

please allow me to bring up another addition planned to be included in
JAX-RS 2.1: Support for Server Sent Events.

The API was introduced a while back [1], but we did incorporate some
changes, mostly alignments with Java SE 8 and another one, slightly more
controversial - alignment with Java SE 9 Flow API.

Why we should use Flow API? We want to make the transition to Java 9 as
smooth as possible. Please note that today, the JAX-RS sources do
contain Flow class (1:1 copy from Java SE 9), but that is NOT a final
state. We want to work with it as much as possible, but we will minimize
and clean up the code before final release. How? Consider following example:

public interface SseBroadcasterextends AutoCloseable, Flow.Publisher<OutboundSseEvent> {

could be modified to

public interface SseBroadcasterextends AutoCloseable {
void subscribe(SseSubscriber<?super OutboundSseEvent> subscriber);

I hope you will like the attempt to be "forward-compatible", but I
assume that this proposal alone will bring some opinions - please share
them! Last note: currently, the Flow API is used only in SSE. We plan to
use it heavily in Non-blocking I/O. If you think there are other areas
where we can take advantage of Subscriber/Publisher methods, please let
us know.

Let me get back to the SSE API.

Very brief description of the API is on the wiki [2], I will expand that
once we'll have some feedback.

The proposal contains support for server and client side. All classes
are in the package [3]. There is no added class from the
last proposal, but there are some changes:

- [server] SseBroadcaster extends Publisher<OutboundSseEvent>
- [server] replaced SseBroadcaster.Listener by
SseBroadcaster#onException and SseBroadcaster#onClose
- [server] SseEventOutput extends Subscriber<OutboundSseEvent>
- [client] SseEventSource extends Publisher<InboundSseEvent>

Corresponding commit [4] looks like a bigger one, but most of it is
renaming based on introduced interfaces, the core of the change is
relatively small.

I look forward to your comments and suggestions.

I don't want to prolong this already too long email - please let me know
if there are some areas which I should describe in more detail.

Thanks and regards,
Pavel & Santiago