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
>