Martin,
Thank you. More questions about default mapping.
1. Do we rellly want to specify ordering of POJO fields based on
lexicographic order of field names?
I think better rely on fields order of appearance in class as it done in
Gson.
2. Inheritance, order of fields. Should we specify default order of fields
when using inheritance? Which field set is to be first - fields of subclass
or fields of superclass? In gson superclass fields go first.
3. We should probably provide examples of ser/deser of composite classes
with injection of normal POJOs instead of using only nested classes in our
examples (one to one relation). WDYT?
4. Lets add examples for POJO classes wth Collections/Arrays fields (one to
many relation).
Thank you
Olena
2015-03-16 12:26 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
> Hi Olena,
>
> makes sense. I will relax this and get rid of the default implementation
> types.
>
> Thank you
>
> MartinV
>
> On Sat, Mar 14, 2015 at 4:17 PM, Olena Syrota <sirotae_at_gmail.com> wrote:
>
>> Hi Martin,
>>
>> let me raise in this thread one more time default implementation issue for
>> Map<String, Object> map =
>> (LinkedHashMap<String,Object>)jsonb.fromJson("{\"name\":\"unknown
>> object\"}", Object.class);
>> and continue our previous discussion. Comments below.
>>
>> ad 3)
>>>
>>> The intention of these examples was to express, that default
>>> implementation of Map should be LinkedHashMap<String, Object>.
>>> Key/value pairs in JSON objects are not ordered, but it is very
>>> practical to have these pairs ordered.
>>>
>>> From my point of view, the most reasonable implementation for JSON array
>>> is ArrayList<Object>.
>>>
>>> If I specify default implementation for JSON object, it makes sense to
>>> specify also default implementation for JSON array (at least for
>>> consistency).
>>>
>>> Other advantage is predictability from the user of this API. If we don't
>>> specify this, this will be probably implemented differently by different
>>> implementations.
>>> I can imagine that different fields could have different implementations
>>> like Arrays.asList(...), Collections.EMPTY_LIST and so on.
>>> This can be problematic in some use cases.
>>> Specifying default implementations (for default mapping) will improve
>>> operability and provide some sensible defaults for the user of the API.
>>>
>>>
>> *I definitely want to hear some other opinions on this topic too. *
>>>
>>> MartinV
>>>
>>
>> If main intention of specifying default implementation of Map interface
>> during unmarshalling from JSON doc is just to preserve ordering in Map
>> structure then why not just specify preserving ordering as requirement
>> in SPEC for provider implementations instead of specifying actual
>> implementation class to be used in this case?
>> This will give more freedom for diff JSON-B providers to supply their own
>> Map implementations if they want. As an example in GSON lib custom data
>> structure is used for Map to preserve ordering.
>>
>> Thank you
>> Olena
>>
>>
>>
>> 2015-03-09 15:10 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>
>>> You are right, thank you.
>>>
>>> Martin
>>>
>>>
>>> On Mon, Mar 9, 2015 at 2:05 PM, Olena Syrota <sirotae_at_gmail.com> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> Absolutly agree.
>>>> Small correction: \" needed at the beginning and the end of the input
>>>> JSON string.
>>>>
>>>> String escapedString = jsonb.fromJson("\" \\\" \\\\ \\/ \\b \\f \\n \\r \\t \\u0039\"", String.class);
>>>>
>>>> Olena
>>>>
>>>>
>>>> 2015-03-06 18:39 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>>>
>>>>> More escaping.
>>>>>
>>>>> assertEquals("\" \\\\ \\\" / \\b \\f \\n \\r \\t 9\"", jsonb.toJson(" \\ \" / \b \f \n \r \t \u0039"));
>>>>>
>>>>> MartinV
>>>>>
>>>>> On Fri, Mar 6, 2015 at 5:32 PM, Martin Vojtek <voytoo_at_gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Olena,
>>>>>>
>>>>>> when I look into
>>>>>> https://github.com/sirotae/jsonb-spec-ua-adopt/tree/master/examples/src/test/java/jug/ua/jsonb/examples/default_mapping
>>>>>>
>>>>>> maybe there should be instead of
>>>>>>
>>>>>> String actual = jsonb.fromJson("\"\b\"", String.class);
>>>>>>
>>>>>> following:
>>>>>>
>>>>>> String actual = jsonb.fromJson("\"\\b\"", String.class);
>>>>>>
>>>>>>
>>>>>> and instead of
>>>>>>
>>>>>> String actual = jsonb.toJson("\b");
>>>>>> assertEquals("\"\b\"", actual);
>>>>>>
>>>>>> should be
>>>>>>
>>>>>> String actual = jsonb.toJson("\b");
>>>>>> assertEquals("\"\\b\"", actual);
>>>>>>
>>>>>>
>>>>>>
>>>>>> Full test:
>>>>>>
>>>>>> //String escaping
>>>>>> String escapedString = jsonb.fromJson(" \\\" \\\\ \\/ \\b \\f \\n \\r \\t \\u0039", String.class);
>>>>>> assertEquals(" \" \\ / \b \f \n \r \t 9", escapedString);
>>>>>>
>>>>>> assertEquals("\" / \\b \\f \\n \\r \\t 9\"", jsonb.toJson(" / \b \f \n \r \t \u0039"));
>>>>>>
>>>>>> MartinV
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 5, 2015 at 5:58 PM, Olena Syrota <sirotae_at_gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> More feedback from Kiev UA JUG (with Oleg Tsal-Tsalko and Andrii
>>>>>>> Rodionov).
>>>>>>>
>>>>>>> 1. JSON value formatting. Let me propose to follow The JSON Data
>>>>>>> Interchange Format (
>>>>>>> http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf).
>>>>>>> Due to this document JSON value is printed without square brackets "[...]".
>>>>>>> Square brakets are used for JSON array.
>>>>>>>
>>>>>>> e.g.
>>>>>>>
>>>>>>> - jsonb.fromJson("1", Byte.class)
>>>>>>>
>>>>>>> instead of
>>>>>>>
>>>>>>> - jsonb.fromJson("[1]", Byte.class), etc.
>>>>>>>
>>>>>>>
>>>>>>> 2. More cases for String mapping should be considered. Due to
>>>>>>> http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf,
>>>>>>> page 5, we should add mapping cases for \", /, \\, \r, \n, \t, \f, \b,
>>>>>>> \uXXXX.
>>>>>>> See
>>>>>>> https://github.com/sirotae/jsonb-spec-ua-adopt/tree/master/examples/src/test/java/jug/ua/jsonb/examples/default_mapping,
>>>>>>> file StringMapping.java
>>>>>>>
>>>>>>> 3. Structure Mapping from Json.
>>>>>>> Case 1. Instead of
>>>>>>>
>>>>>>> - Collection<Object> collection =
>>>>>>> (ArrayList<Object>)jsonb.fromJson("[{\"value\":\"first\"},
>>>>>>> {\"value\":\"second\"}]", Object.class);
>>>>>>>
>>>>>>>
>>>>>>> Let me propose:
>>>>>>>
>>>>>>> - List<Object> act =
>>>>>>> (List)jsonb.fromJson("[{\"value\":\"first\"}, {\"value\":\"second\"}]",
>>>>>>> Object.class);
>>>>>>>
>>>>>>>
>>>>>>> Case 2. Instead of
>>>>>>>
>>>>>>> - Map<String, Object> map =
>>>>>>> (LinkedHashMap<String,Object>)jsonb.fromJson("{\"name\":\"unknown
>>>>>>> object\"}", Object.class);
>>>>>>>
>>>>>>>
>>>>>>> let me propose
>>>>>>>
>>>>>>> - Map<String, Object> map =
>>>>>>> (Map)jsonb.fromJson("{\"name\":\"unknown object\"}", Object.class);
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thank you
>>>>>>> Olena
>>>>>>>
>>>>>>> 2015-03-04 0:05 GMT+02:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
>>>>>>>
>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>