It should be used only for tasks which need to be scheduled. Effectively there is only single task like that in the API right now: delayed reconnect of SseEventSource. Regards,

Hi Pavel, thanks, OK, what about the ScheduledExecutorService - how can the client API implementation know when to use this one if the ExecutorService is also set ?

Hi Sergey, yes, that is correct. Regards, Pavel

Hi Pavel These executor services, if set in the client builder - should they be used in the rx() flows ? Thanks, Sergey

Hi Andy, firstly, thanks for your kind words. Your pull request was merged - good that you brought that up. Thanks! Best regards, Pavel

I have to agree, but we can't do the whole change at this point :-/ I'm adding @throws to Sse, since there is a default implementation in the api, which behaves like that. SseEventSink change could

Ok I agree that we should not touch old APIs, but we should add @throws to new APIs like Sse and SseEventSink then. Also I am not convinced that IAE is only for application callers: Why should it stay

Annotating provider method arguments doesn't make much sense, since they are invoked by the implementation - declaring @throws makes more sense on methods which are invoked directly by the application

Lol ;-D Pavel, I meant the SSE API, actually, but right, I did not check ALL APIs. So to make your claim a valid argument, we should now add @throws IllegalArgumentExcpetion to the JavaDocs of ALL

:-) $ grep -r IllegalArgument . ./javax/ws/rs/BadRequestException.java: * @throws IllegalArgumentException in case the status code set in the response ./javax/ws/rs/BadRequestException.java:

Pavel, actually looking at the rest of the *API* (as you suggested) I did not find declaration of IAE, as it is solely part of the *implementation* -- it is rather undocumented that in particular IAE

Well, if you look at the rest of the API, the pattern is to use IAE even when parameter is null, so .. being consistent with existing API wins over anything else..

So it is by intention that you still use IllegalArgumentException instead of NPE. Understood. :-)

Hi Pavel, Thank you for the clarification, and my apologies for bringing this up so late - a colleague and I ran into some confusion on this point, so I thought I would bring if forward in hopes

Hi Markus, I'm sorry I'm responding so late, I must have missed this email. The main issue with Object.requireNonNull is that it throws a NPE instead of IAE, so we can't really use it on most of

Hi Andy, it is very late for changing anything.. We are not saying that on Java EE environment ClientBuilder#executorService and #scheduledExecutorService have no effect - but it

Hi Pavel, If it is not too late, I'm wondering if we could clarify the uses of ClientBuilder.executorService(...) and scheduledExecutorService(...). Are we saying that in a Java EE environment,

Pavel, from the view of an application programmer the arguments look quite different: SSE within JAX-RS is not recognized as a different technology, but simply as a push-add-on that will keep the

Hi Pavel So, when the SSE server reports a new event which will need to be delivered to SSE Client in for ex JSON, MessageBodyWriter is supported, right ? I'm not

Markus, yes, the issue is that mostly, you wouldn't want to mix "standard" response processing and SSE. MessageBodyWriter is slightly different, since there is a type, the ultimate