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