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