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