In item 3 generics in type cast are omitted by mistake. Accent is that
instead of implementation of collection (ArrayList, linkedHashMap),
interface should be used (List, Map).
Thank you
Olena
2015-03-05 18:58 GMT+02:00 Olena Syrota <sirotae_at_gmail.com>:
> 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
>>>
>>
>>
>