Yeah and glad we can't do that... :p
2015-02-25 11:29 GMT-08:00 Przemyslaw Bielicki <pbielicki_at_gmail.com>:
> Yes exactly like this.
>
> Without typetoken it could be difficult as Optional is a final class thus
> we cannot make custom classes like OptionalFoo extends Optional<Foo>
> 25 lut 2015 19:35 "Eugen Cepoi" <cepoi.eugen_at_gmail.com> napisał(a):
>
> If it is about Optional at the mapping level I am not sure there is a need
>> to make it appear in the spec.
>>
>> The use case I would see with optional at root level is when the root
>> value it self is null... with typetoken could look like (I don't know how
>> you plan to handle generics):
>>
>> Optional<Foo> optFoo = jsonb.fromJson(json, new
>> TypeToken<Optional<Foo>>() {})
>>
>> But the most common would be to have optional nested in Pojo like
>> structures. In that case it would be handled directly by impls.
>>
>>
>> 2015-02-25 5:27 GMT-08:00 Martin Grebac <martin.grebac_at_oracle.com>:
>>
>>> On 25.02.15 8:44, Przemyslaw Bielicki wrote:
>>>
>>>> The trouble with Optional is that it is typed, and as such its use is
>>>>> too complex within the api methods we have now compared to the minimal
>>>>> benefit it brings.
>>>>>
>>>> Anyway I think it should be impl specific feature - sorry for the noise.
>>>>
>>> After re-reading I think I may have been too fast and misunderstood the
>>> usecase. Before I jump into my rant on Optional :) , would you please give
>>> some examples of the expected outcomes, say based on MartinV's default
>>> mapping examples?
>>>
>>> I think it makes sense to get some clarity into this and make decisions
>>> whether the support for Optional should be in the spec, whether it should
>>> be default, and whether it should be spec defined configuration, mostly
>>> because Optional has value wrt lambdas. Thus I also expect the reasoning
>>> will likely have to include the expected stream use? I don't find Optional
>>> bringing any significant value outside of streams.
>>>
>>> MartiNG
>>>
>>>
>>