Date   

Re: JAX-RS 2.1 released!

 

Will you keep us updated on IBM's implementation progress? :-)

-Markus

 

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Andy McCright
Sent: Donnerstag, 24. August 2017 23:03
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] JAX-RS 2.1 released!

 

Congratulations All!

 

It has been a pleasure working with you all on this, and I am looking forward to working with you again in the open source.  

 

Now it is time to implement this spec!  :-)

 

Thanks!

 

Andy



J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...

 

 

----- Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: [jaxrs] JAX-RS 2.1 released!
Date: Thu, Aug 24, 2017 8:46 AM
 

Dear experts,

it's our pleasure to announce that JAX-RS 2.1 was officially released,
see https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jcp.org_en_jsr_detail-3Fid-3D370&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=UpdfB_BfG8Sfl9U7cu9zlMnzlZDpNORv4F5g8rYfZJg&m=cZRJPetic6K09SdI_u-Jjc-vHS2H3QnR0SDXEgGOdhk&s=SnEzQLU5tNb8MPU6q7EUqR7Urx_49nRhVFCRTExYWHk&e= .

Thanks everyone for participating!

Feel free to share this message anywhere, write a blog post, speak about
JAX-RS on conferences.. use whatever channel you think is relevant.

Reference implementation is Jersey in version 2.26, currently available
on java.net promoted maven repository [1]; it will be soon released to
maven central.

Best regards,
Pavel & Santiago

[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__maven.java.net_content_repositories_promoted_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=UpdfB_BfG8Sfl9U7cu9zlMnzlZDpNORv4F5g8rYfZJg&m=cZRJPetic6K09SdI_u-Jjc-vHS2H3QnR0SDXEgGOdhk&s=3nZn6wFCEZLLEl0zfP93CIwMNcsZvlxR8bao3NSDgVc&e= 



 

 

 


Re: JAX-RS 2.1 released!

Sergey Beryozkin
 

Hi Pavel

Nice work - thanks for taking over from Marek and being as great as Marek was :-), being friendly, responsive and patient

Hi Santiago - thanks for your continuing leadership of this effort

Sergey

On 24/08/17 14:48, Pavel Bucek wrote:
Dear experts,

it's our pleasure to announce that JAX-RS 2.1 was officially released, see https://www.jcp.org/en/jsr/detail?id=370.

Thanks everyone for participating!

Feel free to share this message anywhere, write a blog post, speak about JAX-RS on conferences.. use whatever channel you think is relevant.

Reference implementation is Jersey in version 2.26, currently available on java.net promoted maven repository [1]; it will be soon released to maven central.

Best regards,
Pavel & Santiago

[1] https://maven.java.net/content/repositories/promoted/



Re: JAX-RS 2.1 released!

Cassio Mazzochi Molin
 

Great job, guys!

Ah! Following Arjan, +1 for further or even totally integrate with CDI in the next release.


Re: JAX-RS 2.1 released!

Andy McCright
 

Congratulations All!
 
It has been a pleasure working with you all on this, and I am looking forward to working with you again in the open source.  
 
Now it is time to implement this spec!  :-)
 
Thanks!
 
Andy


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 

----- Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: [jaxrs] JAX-RS 2.1 released!
Date: Thu, Aug 24, 2017 8:46 AM
 
Dear experts,

it's our pleasure to announce that JAX-RS 2.1 was officially released,
see https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jcp.org_en_jsr_detail-3Fid-3D370&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=UpdfB_BfG8Sfl9U7cu9zlMnzlZDpNORv4F5g8rYfZJg&m=cZRJPetic6K09SdI_u-Jjc-vHS2H3QnR0SDXEgGOdhk&s=SnEzQLU5tNb8MPU6q7EUqR7Urx_49nRhVFCRTExYWHk&e= .

Thanks everyone for participating!

Feel free to share this message anywhere, write a blog post, speak about
JAX-RS on conferences.. use whatever channel you think is relevant.

Reference implementation is Jersey in version 2.26, currently available
on java.net promoted maven repository [1]; it will be soon released to
maven central.

Best regards,
Pavel & Santiago

[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__maven.java.net_content_repositories_promoted_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=UpdfB_BfG8Sfl9U7cu9zlMnzlZDpNORv4F5g8rYfZJg&m=cZRJPetic6K09SdI_u-Jjc-vHS2H3QnR0SDXEgGOdhk&s=3nZn6wFCEZLLEl0zfP93CIwMNcsZvlxR8bao3NSDgVc&e= 



 
 


Re: JAX-RS 2.1 released!

Arjan Tijms
 

On Thu, Aug 24, 2017 at 09:09 am, Markus KARG wrote:
Congratulations! When do we start with JAX-RS 2.2? ;-)
Good question indeed. I'd say that even without a JSR we can already discuss our wishlists, can't we?

My nr 1 item; further or even totally integrate with CDI ;)

Kind regards,
Arjan


Re: JAX-RS 2.1 released!

 

Congratulations! When do we start with JAX-RS 2.2? ;-)

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Donnerstag, 24. August 2017 15:49
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] JAX-RS 2.1 released!

Dear experts,

it's our pleasure to announce that JAX-RS 2.1 was officially released, see https://www.jcp.org/en/jsr/detail?id=370.

Thanks everyone for participating!

Feel free to share this message anywhere, write a blog post, speak about JAX-RS on conferences.. use whatever channel you think is relevant.

Reference implementation is Jersey in version 2.26, currently available on java.net promoted maven repository [1]; it will be soon released to maven central.

Best regards,
Pavel & Santiago

[1] https://maven.java.net/content/repositories/promoted/


Re: JAX-RS 2.1 released!

Guillermo González de Agüero
 

Congratulations and thanks Pavel, Santiago and everyone involved on this release!

Now that the spec is complete, any plans to move the JAX-RS repositories under the Java EE organization?


Regards,

Guillermo González de Agüero


El jue., 24 de agosto de 2017 15:46, Pavel Bucek <pavel.bucek@...> escribió:
Dear experts,

it's our pleasure to announce that JAX-RS 2.1 was officially released,
see https://www.jcp.org/en/jsr/detail?id=370.

Thanks everyone for participating!

Feel free to share this message anywhere, write a blog post, speak about
JAX-RS on conferences.. use whatever channel you think is relevant.

Reference implementation is Jersey in version 2.26, currently available
on java.net promoted maven repository [1]; it will be soon released to
maven central.

Best regards,
Pavel & Santiago

[1] https://maven.java.net/content/repositories/promoted/





JAX-RS 2.1 released!

Pavel Bucek
 

Dear experts,

it's our pleasure to announce that JAX-RS 2.1 was officially released, see https://www.jcp.org/en/jsr/detail?id=370.

Thanks everyone for participating!

Feel free to share this message anywhere, write a blog post, speak about JAX-RS on conferences.. use whatever channel you think is relevant.

Reference implementation is Jersey in version 2.26, currently available on java.net promoted maven repository [1]; it will be soon released to maven central.

Best regards,
Pavel & Santiago

[1] https://maven.java.net/content/repositories/promoted/


Re: Question on CompletionStage

Sergey Beryozkin
 

Hi Pavel

On 22/08/17 17:29, Pavel Bucek wrote:

Hi Sergey,

I guess that's fine, unless someone registers MessageBodyWriter for Observable, which might then now work properly.

You are right technically having MBW<Observable> is a possibility but practically speaking I can't see anyone doing it, though this is how I started from myself, but it might only work for something like Observable.just("Hello World")

I'm not saying that because I think that it shouldn't be done, its just something which is not defined by the specification and JAX-RS user can't rely on this to work everywhere.

// and I'm certainly not saying that we won't do something like that for Jersey :)


Yeah, lets go beyond the spec limits a bit :-)

Thanks, Sergey

Thanks and regards,
Pavel


On 22/08/2017 16:58, Sergey Beryozkin wrote:
Hi Pavel

FYI, in CXF returning Observable will be handled similarly to returning CompletionStage

Cheers, Sergey
On 22/08/17 09:06, Pavel Bucek wrote:

Hi Markus,

confirming what you wrote would be extending of what is pretty explicitly written in the spec, so I can't do that.

Currently, the behavior is "defined" by what AsyncResponse provides and there is nothing like you mentioned there, so I don't think that the usecase you described is supported - returned Observable (or any other type) will be processed as any other type, so the pipeline will be triggered right after the object is returned from the resource method.

Returning CompletionStage is equal to invoking AsyncResponse#resume in CompletionStage#whenComplete callback, nothing more, nothing less..

Regards,
Pavel


On 18/08/2017 17:23, Markus KARG wrote:

Pavel,

 

as the spec does not explicitly mention it, can you please confirm that what the spec actually wants to say is that CompletionStage does not only imply async when declared as a method's return type, but also when CompletionStage is de-facto returned by a method or by a interceptor (i. e. the method itself is not declared to return CompletionStage, but might return Object and an interceptor produces a CompletionStage from that)? This would allow framework providers to provide "JAX-RS adapter" like an interceptor turning RxJava's Observable into Java 8's CompletionStage. The spec is a bit short here.

 

Thanks

-Markus






Re: Question on CompletionStage

 

I think it make sense to file this as an issue for JAX-RS 2.2 / 3.0, so a future specification will align CXF and Jersey and give application developers safety how things shall work.

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Dienstag, 22. August 2017 18:29
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] Question on CompletionStage

 

Hi Sergey,

I guess that's fine, unless someone registers MessageBodyWriter for Observable, which might then now work properly.

I'm not saying that because I think that it shouldn't be done, its just something which is not defined by the specification and JAX-RS user can't rely on this to work everywhere.

// and I'm certainly not saying that we won't do something like that for Jersey :)

Thanks and regards,
Pavel

 

On 22/08/2017 16:58, Sergey Beryozkin wrote:

Hi Pavel

FYI, in CXF returning Observable will be handled similarly to returning CompletionStage

Cheers, Sergey
On 22/08/17 09:06, Pavel Bucek wrote:

Hi Markus,

confirming what you wrote would be extending of what is pretty explicitly written in the spec, so I can't do that.

Currently, the behavior is "defined" by what AsyncResponse provides and there is nothing like you mentioned there, so I don't think that the usecase you described is supported - returned Observable (or any other type) will be processed as any other type, so the pipeline will be triggered right after the object is returned from the resource method.

Returning CompletionStage is equal to invoking AsyncResponse#resume in CompletionStage#whenComplete callback, nothing more, nothing less..

Regards,
Pavel

 

On 18/08/2017 17:23, Markus KARG wrote:

Pavel,

 

as the spec does not explicitly mention it, can you please confirm that what the spec actually wants to say is that CompletionStage does not only imply async when declared as a method's return type, but also when CompletionStage is de-facto returned by a method or by a interceptor (i. e. the method itself is not declared to return CompletionStage, but might return Object and an interceptor produces a CompletionStage from that)? This would allow framework providers to provide "JAX-RS adapter" like an interceptor turning RxJava's Observable into Java 8's CompletionStage. The spec is a bit short here.

 

Thanks

-Markus

 

 

 


Re: Question on CompletionStage

Pavel Bucek
 

Hi Sergey,

I guess that's fine, unless someone registers MessageBodyWriter for Observable, which might then now work properly.

I'm not saying that because I think that it shouldn't be done, its just something which is not defined by the specification and JAX-RS user can't rely on this to work everywhere.

// and I'm certainly not saying that we won't do something like that for Jersey :)

Thanks and regards,
Pavel


On 22/08/2017 16:58, Sergey Beryozkin wrote:
Hi Pavel

FYI, in CXF returning Observable will be handled similarly to returning CompletionStage

Cheers, Sergey
On 22/08/17 09:06, Pavel Bucek wrote:

Hi Markus,

confirming what you wrote would be extending of what is pretty explicitly written in the spec, so I can't do that.

Currently, the behavior is "defined" by what AsyncResponse provides and there is nothing like you mentioned there, so I don't think that the usecase you described is supported - returned Observable (or any other type) will be processed as any other type, so the pipeline will be triggered right after the object is returned from the resource method.

Returning CompletionStage is equal to invoking AsyncResponse#resume in CompletionStage#whenComplete callback, nothing more, nothing less..

Regards,
Pavel


On 18/08/2017 17:23, Markus KARG wrote:

Pavel,

 

as the spec does not explicitly mention it, can you please confirm that what the spec actually wants to say is that CompletionStage does not only imply async when declared as a method's return type, but also when CompletionStage is de-facto returned by a method or by a interceptor (i. e. the method itself is not declared to return CompletionStage, but might return Object and an interceptor produces a CompletionStage from that)? This would allow framework providers to provide "JAX-RS adapter" like an interceptor turning RxJava's Observable into Java 8's CompletionStage. The spec is a bit short here.

 

Thanks

-Markus





Re: Question on CompletionStage

Sergey Beryozkin
 

Hi Pavel

FYI, in CXF returning Observable will be handled similarly to returning CompletionStage

Cheers, Sergey

On 22/08/17 09:06, Pavel Bucek wrote:

Hi Markus,

confirming what you wrote would be extending of what is pretty explicitly written in the spec, so I can't do that.

Currently, the behavior is "defined" by what AsyncResponse provides and there is nothing like you mentioned there, so I don't think that the usecase you described is supported - returned Observable (or any other type) will be processed as any other type, so the pipeline will be triggered right after the object is returned from the resource method.

Returning CompletionStage is equal to invoking AsyncResponse#resume in CompletionStage#whenComplete callback, nothing more, nothing less..

Regards,
Pavel


On 18/08/2017 17:23, Markus KARG wrote:

Pavel,

 

as the spec does not explicitly mention it, can you please confirm that what the spec actually wants to say is that CompletionStage does not only imply async when declared as a method's return type, but also when CompletionStage is de-facto returned by a method or by a interceptor (i. e. the method itself is not declared to return CompletionStage, but might return Object and an interceptor produces a CompletionStage from that)? This would allow framework providers to provide "JAX-RS adapter" like an interceptor turning RxJava's Observable into Java 8's CompletionStage. The spec is a bit short here.

 

Thanks

-Markus




Re: Question on CompletionStage

Pavel Bucek
 

Hi Markus,

confirming what you wrote would be extending of what is pretty explicitly written in the spec, so I can't do that.

Currently, the behavior is "defined" by what AsyncResponse provides and there is nothing like you mentioned there, so I don't think that the usecase you described is supported - returned Observable (or any other type) will be processed as any other type, so the pipeline will be triggered right after the object is returned from the resource method.

Returning CompletionStage is equal to invoking AsyncResponse#resume in CompletionStage#whenComplete callback, nothing more, nothing less..

Regards,
Pavel


On 18/08/2017 17:23, Markus KARG wrote:

Pavel,

 

as the spec does not explicitly mention it, can you please confirm that what the spec actually wants to say is that CompletionStage does not only imply async when declared as a method's return type, but also when CompletionStage is de-facto returned by a method or by a interceptor (i. e. the method itself is not declared to return CompletionStage, but might return Object and an interceptor produces a CompletionStage from that)? This would allow framework providers to provide "JAX-RS adapter" like an interceptor turning RxJava's Observable into Java 8's CompletionStage. The spec is a bit short here.

 

Thanks

-Markus



Question on CompletionStage

 

Pavel,

 

as the spec does not explicitly mention it, can you please confirm that what the spec actually wants to say is that CompletionStage does not only imply async when declared as a method's return type, but also when CompletionStage is de-facto returned by a method or by a interceptor (i. e. the method itself is not declared to return CompletionStage, but might return Object and an interceptor produces a CompletionStage from that)? This would allow framework providers to provide "JAX-RS adapter" like an interceptor turning RxJava's Observable into Java 8's CompletionStage. The spec is a bit short here.

 

Thanks

-Markus


Re: Final API Publication

Sergey Beryozkin
 

Hi Pavel

Thanks, it is in Central now

Sergey

On 07/08/17 06:32, Pavel Bucek wrote:
I'm sorry for the delay.

I believe I'll be able release the API to be published to maven central today. (If you need it now, feel free to use:

https://maven.java.net/content/repositories/promoted/javax/ws/rs/javax.ws.rs-api/2.1/

Regards,
Pavel


On 04/08/2017 15:36, Pavel Bucek wrote:
Hi Sergey,

it will be .. soon. I'm aiming for today / this weekend.

Regards,
Pavel

On 04/08/2017 14:46, Sergey Beryozkin wrote:
Hi Pavel

When will the final API be published to Maven Central ?
31 July was the finish of the Final Approval Ballot

Thanks, Sergey




Re: Final API Publication

Pavel Bucek
 

I'm sorry for the delay.

I believe I'll be able release the API to be published to maven central today. (If you need it now, feel free to use:

https://maven.java.net/content/repositories/promoted/javax/ws/rs/javax.ws.rs-api/2.1/

Regards,
Pavel

On 04/08/2017 15:36, Pavel Bucek wrote:
Hi Sergey,

it will be .. soon. I'm aiming for today / this weekend.

Regards,
Pavel

On 04/08/2017 14:46, Sergey Beryozkin wrote:
Hi Pavel

When will the final API be published to Maven Central ?
31 July was the finish of the Final Approval Ballot

Thanks, Sergey


Re: Final API Publication

Pavel Bucek
 

Hi Sergey,

it will be .. soon. I'm aiming for today / this weekend.

Regards,
Pavel

On 04/08/2017 14:46, Sergey Beryozkin wrote:
Hi Pavel

When will the final API be published to Maven Central ?
31 July was the finish of the Final Approval Ballot

Thanks, Sergey


Final API Publication

Sergey Beryozkin
 

Hi Pavel

When will the final API be published to Maven Central ?
31 July was the finish of the Final Approval Ballot

Thanks, Sergey


Status of JAX-RS 2.1 Implementations

 

Last thursday I gave a talk on JAX-RS 2.1 at JFS2017 conference using Jersey 2.26. One question was what the status of the JAX-RS implementations is _besides_ Jersey. Hence I would like to kindly ask for a short "official" statement on the current status and scheduled GA for JAX-RS 2.1 in (at least) the propducts of the EG members and / or other vendors:

 

* Apache

* Red Hat

* Payara

* IBM

* Oracle non-pure-Jersey

* others

 

Please note that the intention is to publish these statements for the sake of public announcement of JAX-RS 2.1 cross-industry support.

 

thanks

-Markus


Re: Proposed Final Draft

Sergey Beryozkin
 

I thought I'd check the docs first before asking, and obviously I missed this one:

https://github.com/jax-rs/api/blob/master/jaxrs-api/src/main/java/javax/ws/rs/client/ClientBuilder.java#L275

:-)

Thanks, Sergey

On 11/07/17 11:59, Pavel Bucek wrote:

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,
Pavel


On 11/07/2017 12:52, Sergey Beryozkin wrote:
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 ?

Cheers, Sergey

On 11/07/17 10:12, Pavel Bucek wrote:

Hi Sergey,

yes, that is correct.

Regards,
Pavel


On 11/07/2017 10:35, Sergey Beryozkin wrote:
Hi Pavel

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

Thanks, Sergey 
On 11/07/17 00:12, Pavel Bucek wrote:

Hi Andy,

firstly, thanks for your kind words.

Your pull request was merged - good that you brought that up. Thanks!

Best regards,
Pavel


On 07/07/2017 14:38, Andy McCright wrote:
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 that other users might avoid a similar confusion.
 
I have opened a pull request [1] with my suggested changes to the javadoc.  I think this may help users better understand the differences in the Java SE vs EE environments.
 
Thanks again - it has been a pleasure working with you in this expert group!
 
Andy
 
[1] https://github.com/jax-rs/api/pull/560

J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Proposed Final Draft
Date: Fri, Jul 7, 2017 12:25 AM
 

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 might sound that way.

The "default" for Java SE is NOT ForkJoinPool#commonPool, since it is not meant for I/O operations. On Java SE, the default is intentionally left as implementation specific.

And I'm not sure what you mean by "what about Future Objects returned from ..." - if there is any need for starting a thread, it should be done on the executor service provided in the client builder. Note that the javadoc for ClientBuilder#executorService mentions:

* Provided executor service will be used for executing asynchronous tasks.

And Invocation#buildGet() (and others):

* Submit the request for an asynchronous invocation and receive a future
* response back.

Which seem to imply what I wrote..

It might be still possible to tweak the javadoc, I'll wait for your reaction - whether this makes sense or not and then will inquire about possible javadoc adjustment.

Thanks and regards,
Pavel


On 07/07/2017 00:35, Andy McCright wrote:
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, these methods have no effect?  If so, can we change this text:
When running in a Java EE container, implementations are required to use the container-managed executor service.
 
to:
When running in a Java EE container, this method will have no effect.  The container will always use the container-managed executor service.
 
and a similar change for the executorService method?
 
 
If instead we are saying that in a Java EE container, the default ES and SES are different than in Java SE, we should clarify it like this:
When running in a Java EE container, the default scheduled executor service will be the container-managed service.  In Java SE, this will be the ForkJoinPool service.
 
 
I think we should also clarify what methods will use these services.  The javadoc currently provides some guidance with:
     * @see Invocation.Builder#async()
     * @see Invocation.Builder#rx()
     * @see RxInvokerProvider#getRxInvoker(SyncInvoker, ExecutorService)
and
     * @see SseEventSource.Builder#reconnectingEvery(long, TimeUnit)
 
but what about Future objects returned from methods like buildGet().submit(...)?
 
Thanks,
 
Andy
 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: [jaxrs] Proposed Final Draft
Date: Thu, Jun 22, 2017 6:18 AM
 
Dear experts,

we'd like to announce that Proposed Final Draft was published on JCP JSR
370 page [1].

I'd like to encourage you all to review provided artifacts and let us
know if you have any feedback.

Thanks and regards,
Pavel & Santiago

[1] https://jcp.org/en/jsr/detail?id=370