Hi all,
what about byte[] serialization and deserialization to/from base64?
For me its natural (like proposed by MartinV) so ser/deser into a
array of bytes like [3,-1,33,-11] but some json binding frameworks out
there ser/deser byte[] to/from a base64 encoded string by default.
To make the spec compatible with them maybe we should consider to support both?
Wdyt?
Thanks
Hendrik
On Fri, Feb 27, 2015 at 5:45 PM, Martin Grebac <martin.grebac_at_oracle.com> wrote:
>
> 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
>
--
Hendrik Saly (salyh, hendrikdev22)
@hendrikdev22
PGP: 0x22D7F6EC