Hi
On 02/11/11 09:19, Marek Potociar wrote:
> Hi Markus,
> Thanks for chiming in. Interesting way of looking a this. personally I am not big fan on using old style with generic
> types, but I see your point. I'll make sure include this in my considerations.
Lets try to get a complete solution out there if possible, for the
tooling be able to deduce the info about all the types a given resource
method may return.
Cheers, Sergey
>
> Marek
>
> On 11/01/2011 05:53 PM, Markus KARG wrote:
>> Marek,
>>
>> while I do not see an urgent need for generic response, I can understand that from the tooling side this is a valid issue. So why not doing it? People not wanting the type information can just keep the old style "Response" (without diamond), and in the end, it would be just "correct" to give the type information even if not needed (just as we all meanwhile are used to give it to Collection<>, even if our programs would run fine without). So I do not see any real problem it would imply.
>>
>> Regards
>> Markus
>>
>>> -----Original Message-----
>>> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
>>> Sent: Freitag, 14. Oktober 2011 18:21
>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>> Subject: [jsr339-experts] Making Request/Response + builders generic?
>>>
>>> Hello experts,
>>>
>>> we've privately received some suggestions to make Req/Resp + builders
>>> generic.
>>>
>>> + The advantage would be the type safety as well as potential to
>>> + preserve type information so that GenericEntity does
>>> not have to be utilized directly (e.g. HTTP resource methods that
>>> produce Response currently would be able to better declare the actual
>>> response entity type, provided the entity types produced share a common
>>> ancestor).
>>>
>>> - The main disadvantage I can think of is that generic req/response
>>> processing would (if correctly typed) require the extra "<?>" in many
>>> scenarios.
>>>
>>> Thoughts?
>>>
>>> Marek
>>