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