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