Hi,
We (JSR 371) would be really grateful if the following could be added to
the list of candidates as well:
https://java.net/jira/browse/JAX_RS_SPEC-532
https://java.net/jira/browse/JAX_RS_SPEC-533
Regards,
Ivar
On Wed, Apr 5, 2017 at 11:01 AM Pavel Bucek <pavel.bucek_at_oracle.com> wrote:
> Hi Sebastian,
>
> we currently have the list of tasks pre-selected as "2.1-candidate", see
>
> https://java.net/jira/issues/?jql=cf%5B10002%5D%20%3D%202.1-candidate
>
> The list is not final. There is no priority yet. We most likely won't be
> able to address all issues.
>
> Also, we need to clear up the spec (internal review in progress), which
> means remove Flow and its subinterfaces and references to these.
>
> Regards,
> Pavel
>
> On 05/04/2017 07:44, Sebastian Daschner wrote:
>
> Hi there,
>
> I agree that we should agree on a reasonable API before adding it to the
> spec forever. Especially the case with the Flow type will be an issue in
> JDK 9.
>
> I highly welcome that we want to work on smaller improvements though. As
> there are already JIRA issues for these, should be compile a list sorted by
> priority and start from the top?
>
> Maybe everybody can vote on JIRA if they haven't already.
>
> Cheers,
> Sebastian
>
>
> On 04/03/2017 06:40 PM, Pavel Bucek wrote:
>
> Dear EG members,
> As you all know we have been hard at work trying to come up with an NIO
> proposal based on Flows. In doing so, we have come to the conclusion that
> this is indeed a really hard problem --lots of small details that need
> double clicking! After some deliberation, we have come to the conclusion
> that it is better to drop this feature from this dot release. Here is the
> rationale for doing so:
>
> - Working backwards from the officially committed Java EE 8 release date
> - July 2017 - we need to start Public Review in the middle of April, which
> means that at this point we don't have enough time to do a design,
> implementation prototype and gather appropriate feedback.
> - Current proposal is based on a Flow-like API, which would force us to
> duplicate the JDK 9 Flow concept in the JAX-RS 2.1 API.
> - We don't want to introduce "just another non-blocking API", which might
> be deprecated very soon (when Java 9 is released).
> - We need some time to work on "smaller issues", which would be most
> likely not possible if we'll continue working on NIO.
>
> *What does that mean for the current state of the API?*
>
> We will remove Flow.* interfaces and its usage in existing APIs, which
> means adjustments in SSE part of the spec. Also, we will be making at least
> some improvement, more related to already introduced Reactive API - support
> for returning CompletionStage from the resource method. It was in our last
> version of the high level non-blocking API; CompletionStage is basically a
> Mono - publisher of a single item. Resource method could then look like:
>
> @POST_at_Path("acceptProduceSource")public CompletionStage<AnotherPOJO> echoNioEntity(POJO requestEntity) {
>
> // not blocking the thread, returning CompletionStage and doing the work elsewhere. return ...;
>
> }
>
> This improvement will simplify use of the new JAX-RS 2.1 reactive client
> API in a JAX-RS resource method. Note that this is already tracked as
> https://java.net/jira/browse/JAX_RS_SPEC-546.
> As always, any comments or suggestions are appreciated.
>
> Thanks and regards,
> Pavel & Santiago
>
>
>
> --
Java Champion, JCP EC/EG Member, JUG Leader