Hi Guilherme,
I am not a fan of this approach either, but it seems to be the least verbose way to be able to define e.g.
ClientRequest.Builder interface like this:
public static interface Builder extends InvocationBuilder<Builder> {
/**
* Build the {_at_link ClientRequest} instance.
*
* @param uri the URI of the request.
* @param method the HTTP method.
* @return the client request.
*/
public ClientRequest build(URI uri, String method);
}
...without the need to redefine all the InvocationBuilder methods to return instance of ClientRequest.Builder.
Marek
On 05/09/2011 05:29 PM, Guilherme Silveira wrote:
> Hi Marek,
>
> Not an objection, but just a comment. I am not the biggest fan of
> generics for return type covariance as in here:
> +public interface InvocationBuilder<T extends InvocationBuilder>
>
> But its just a comment, with or without it, the API provider is
> capable of doing:
>
> public interface IB {
> IB type();
> }
>
> public class MyIB implements IB {
> MyIB type();
> }
>
> Regards
>
> Guilherme Silveira
> Caelum | Ensino e Inovação
> http://www.caelum.com.br/
>
>
>
> On Thu, May 5, 2011 at 5:02 PM, Marek Potociar
> <marek.potociar_at_oracle.com> wrote:
>> Hello experts,
>>
>> Please have a look at the comments & patch attached to the ClientRequest.Builder vs. ClientRequestBuilder clarifiaction
>> task in Jira: http://java.net/jira/browse/JAX_RS_SPEC-78
>>
>> Also, please have a look at the comments & patch attached to the Jira task that is meant to explore possibilities of
>> unifying sync and async HTTP method invocation in a single web resource class: http://java.net/jira/browse/JAX_RS_SPEC-75
>>
>> Please review both proposals and add any feedback to the tasks as comments or send it via email to the EG list.
>>
>> If there are no objections, I plan to push the proposed patches to the public repository by Monday.
>>
>> Thank you,
>> Marek
>>