Please ignore the last point - bad example. Will provide multiple
examples within the generics topic.
MartiNG
On 27.02.15 10:03, Martin Grebac wrote:
> On 25.02.15 20:29, Przemyslaw Bielicki wrote:
>>
>> Yes exactly like this.
>>
> Not sure exactly like what - are you suggesting both scenarios? Root
> level as well as nested?
>
>> 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
>> <mailto: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.
>>
> In spec we have to define (or decide to not to define) the behaviour
> for Optional within default mapping at least to not cause portability
> problems.
>
>> 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>>() {})
>>
> What is the value that this support brings to JSON Binding? Does this
> have value for further work with optFoo?
> The call requires constructing the specific type, requires us to
> remove type checking from the method signature which is useful in
> non-generic cases, and I'm not sure about the value or problem it
> actually solves.
>
>> But the most common would be to have optional nested in Pojo like
>> structures. In that case it would be handled directly by impls.
>>
> We're again inherently discussing generics here with Optional, too.
> And the same as above applies - we need portable behaviour. So, let's
> say we have
>
> public class B {
> Optional<C> c;
> }
> public class C {
> Optional<List<Optional<String>>> s;
> OptionalInt i;
> D<String,Long> d;
> }
> public class D<T1,T2> {
> List<T1> l1;
> Optional<T2> t2;
> }
>
> And you want to be marshalling / unmarshalling from / into this
> structure. How would the implementation at runtime be able to defer
> and create proper types for the individual properties?
>
> MartiNG
>
>> 2015-02-25 5:27 GMT-08:00 Martin Grebac <martin.grebac_at_oracle.com
>> <mailto: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
>>
--
Martin Grebac, SW Engineering Manager
Oracle Czech, Prague