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