jsr367-experts@jsonb-spec.java.net

[jsr367-experts] Re: [jsonb-spec users] Re: [2-DefaultMapping] Proposal

From: Eugen Cepoi <cepoi.eugen_at_gmail.com>
Date: Tue, 3 Mar 2015 14:05:52 -0800

The way byte arrays are being ser/de can be a config. option.
The advantage of base64 is that it produces much smaller json than using an
array.
I didn't benchmark ser/de speed when using one or the other but I guess the
difference is probably not so big.

Eugen

2015-03-03 13:47 GMT-08:00 Hendrik Dev <hendrikdev22_at_gmail.com>:

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