[jax-rs-spec users] [jsr339-experts] Re: Re: A proposal to make the JAX-RS API "lambda ready".

From: Marek Potociar <>
Date: Wed, 31 Oct 2012 10:50:21 +0100

On Oct 30, 2012, at 4:02 PM, Sergey Beryozkin <> wrote:

> On 29/10/12 11:06, Marek Potociar wrote:
>> Hello experts,
>> A month ago at JavaOne, making APIs ready for closure support that is
>> coming in Java SE 8, was one of the hot topics. The main idea behind
>> making an API ready for "lambdas" (or closures), is to expose
>> single-method interfaces whenever one expects a future use of lambdas.
>> In JAX-RS 2.0, such places include definition of async response
>> callbacks as well as client-side invocation callback.
>> With that I took a stab on it and tried to come up with a proposal that
>> would make our new APIs more lambda-ready. Please review the proposal here:
>> In summary, I have updated the client.InvocationCallback to have only a
>> single method and since I anticipate that many users would still prefer
>> the old 2-method style, I'm adding an AbstractInvocationCallback
>> convenience class. On the side of async response container callbacks,
>> I've similarly updated the CompletionCallback and ResumeCallback APIs to
>> adopt a single-method pattern. In my last commit I've also decided
>> (based on numerous Sergey's requests) to propose removal of
>> ResumeCallback (for now).
> I've already implemented a support for it :-).

Well, so did we. Including all other APIs we're proposing to change...

> Yes, I was questioning, given that I was not sure about the actual cases but I guess in the end I thought, well, who knows, may be someone will need it so I typed the code :-). I'm fine with removing this new code I typed, as you implied it can be reintroduced immediately when someone does have a specific requirement, either approach is ok for me

Ok, thanks. I am proposing to remove as there is no clear use case and making the interface lambda-ready would be complicated. Perhaps once we have a better idea about concrete use cases, we'll be able to design the API in a way that supports those use cases and is still lambda-ready.


> Sergey
>> I'm looking forward to your review comments.
>> Marek