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 @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
>>
>