rest
rest copied to clipboard
jakartaee
Integration with Jakarta Concurrency 3.0
I would like to suggest that we add a new section under section 11.2 Integrations with Jakarta EE Technologies for Jakarta Concurrency 3.0. In particular, I think that when a user passes a ManagedExecutorService to the ClientBuilder.executorService(...) method, that we ensure that implementations return CompletionStage objects using the new methods added to Concurrency 3.0 in issue https://github.com/eclipse-ee4j/concurrency-api/issues/40
This would resolve the nondeterministic problems listed in the issue and make it portable - at least for environments that support Jakarta Concurrency 3.0.
@andymc12 Are you thinking about this for 3.1 or 4.0? At first glance, it seems this may be challenging from a TCK perspective for 3.1.
I was thinking 3.1. For the TCK tests, could we do something like register something with JNDI, then have a client request filter abort with a response (in one case, it should provide an immediate response so the the CompletionStage is completed immediately, and another case where it delays the response by a few seconds), then have the client attempt to look up the JNDI entry upon the completion of the initial stage. If both the immediate and delayed stages can successfully look up the entry, then it should pass. Wdyt?
Otherwise, if it's better to wait until 4.0, that works for me too. Thanks.
My preference would be to do this in 4.0. I'd like to hear other opinions, though.
My preference is to defer all not-yet-implemented API changes to post-3.1 to not further delay the next release.
Delaying to 4.0 works for me. My concern was that I wanted to see this integration occur in the same EE release that includes Jakarta Concurrency 3.0. It sounds like RESTful WS 3.1 will be a standalone release and 4.0 will be included in EE10 (with Concurrency 3.0). So waiting for 4.0 definitely seems like the right choice. Thanks @spericas and @mkarg!
@andymc12 I see 3.1 as a standalone milestone on the way towards 4.0, and EE 10 should include 4.0 not 3.1. In the sense of "release early release often" we should try to produce 2-4 such milestones per year, and a "big" JAX-RS release ontop.
For Jakarta Rest 4.0 should this be changed to "Integration with Jakarta Concurrency 3.1" which will include support for Virtual threads in Java 21?
For Jakarta Rest 4.0 should this be changed to "Integration with Jakarta Concurrency 3.1" which will include support for Virtual threads in Java 21?
AFAIK the support for Virtual Threads in Jakarta Concurrency is still being debated.
AFAIK the support for Virtual Threads in Jakarta Concurrency is still being debated.
Yes, perhaps that part of my statement is premature. But regardless of whether Jakarta Concurrency 3.1 includes virtual thread support or not, this issue should probably change to "Integration with Jakarta Concurrency 3.1" no?
Of course, without consideration of virtual threads there may not be much of an impact.
It makes sense to me in general to use the latest specs really. My comment was only attempting to point it's not quite finalized yet :)
Yes, valid point. I'm not entirely sure what impact virtual threads would have on Jakarta Rest anyway, beyond TCK tests to cover opt-in and opt-out scenarios involving ManagedExectutors. Standing by :-)
@jim-krueger Not a significant impact, other than maybe some text in the spec describing their benefits. There are a few features in Jakarta REST around async/reactive that become far less interesting when I/O-blocking of threads is acceptable (or even encouraged). Application code will be simpler in those cases.