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