users@jsonb-spec.java.net

[jsonb-spec users] [jsr367-experts] Re: Re: Re: Re: Re: Re: Re: JSONB De/Serializers proposal

From: Romain Manni-Bucau <rmannibucau_at_tomitribe.com>
Date: Tue, 10 May 2016 16:30:28 +0200

2016-05-10 15:51 GMT+02:00 Roman Grigoriadi <roman.grigoriadi_at_oracle.com>:

>
>
> On 05/10/2016 03:37 PM, Romain Manni-Bucau wrote:
>
>
> 2016-05-10 15:26 GMT+02:00 Roman Grigoriadi <roman.grigoriadi_at_oracle.com>:
>
>>
>>
>> On 05/10/2016 08:14 AM, Romain Manni-Bucau wrote:
>>
>> Ok, let step back. Before all *technically* I fully agree with you. Why I
>> defend a different position is from my experience a lot of people will not
>> be able to use such an API so i'm trying to ensure our API is adopted
>> whatever use case we support.
>>
>> Whats wrong with JsonParser API from user perspective? If JsonStructure
>> is needed instead of event driven api, it can be provided by mapper API (as
>> Eugene mentioned). JsonParser will be at START_OBJECT position when passed
>> to deserializer, so user can get JsonStructure for whole deserializer
>> root/return type. Furthermore, according to JSONP master branch, looks like
>> there will be methods for getting JsonArray/JsonObject directly on
>> JsonParser since JSONP 1.1 release.
>>
>>
>>
> Proposal is just to add an abstract child already doing
> context.deserialize(JsonObject.class, parser) and giving as parameter the
> JsonObject instead of the parser. Making it direct and not requiring users
> to look for this or to know they have to pass JsonObject.class as parameter
> is good enough.
>
> But wouldn't it be redundant after JSONP 1.1, which has those already in
> JsonParser?
>
>
>
>
Maybe but it doesn't cost much and makes it an easier entry point for
several users so I think it does worth it.


> Secondly the fact jsonp doesnt support writeKey()writeValue() doesnt
>> prevent us to do it (we actually do since we have the key before the value
>> in the mapper model ;)).
>>
>> Didn't get this one, we do writeStartObject(String key), and
>> writeEndObject() in the mapper.
>>
>>
> In the API or the impl? Globally point is we can support a single
> serialize method as mentionned by Eugen.
>
> Ok, I missed the point.
>
>
>
>>
>> It means I think we can go for Eugen proposal BUT to support my case too
>> we would need a subclass/abstract impl giving the JsonReader (read(parser,
>> Object) doesn't work, see polymorphism thread).
>>
>> Would it be a good compromise?
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>> 2016-05-10 0:46 GMT+02:00 Eugen Cepoi < <cepoi.eugen_at_gmail.com>
>> cepoi.eugen_at_gmail.com>:
>>
>>> Ahh damn I remember now... in jsonp we have a separate methods to be
>>> used inside objects which takes the key and others without the key, but you
>>> can't first write the key and then write the value...which sucks. I should
>>> have insisted more on that :p
>>>
>>> So in short my comment is irrelevant as I was assuming that we have
>>> writeName+writeValue methods in JsonGenerator...so yeah in this case there
>>> is no choice, we need serialize methods that take a key and another that
>>> doesn't... :(
>>>
>>> 2016-05-09 15:22 GMT-07:00 Dmitry Kornilov <
>>> <dmitry.kornilov_at_oracle.com>dmitry.kornilov_at_oracle.com>:
>>>
>>>>
>>>> I also think that passing jsonp parser/generator as an argument is OK.
>>>>> The question here is that we are forcing implementations to use
>>>>> parser/generator. What if (as Romain mentioned somewhere in this thread)
>>>>> some implementations will use reader/writer as a parsing mechanism? Shall
>>>>> we consider this option? Folks, I need you opinion here.
>>>>>
>>>>>
>>>> JsonReader/writer just deal with the full dom structures, to get a dom
>>>> structure one could simply do ctx.deserialize(JsonObject.class, stream).
>>>> So I think it is just fine and is the right thing to do: use the low
>>>> level jsonp api.
>>>>
>>>>
>>>> Agree.
>>>>
>>>> But there is another use case. What if we have a list inside an object
>>>>> we are serializing.
>>>>>
>>>>> public class Create {
>>>>> public List items;
>>>>> }
>>>>>
>>>>> For some reason we don’t want to serialize items list using
>>>>> context.serialize(“items”, crate.items, generator).
>>>>> We want to serialize each item manually in a cycle.
>>>>>
>>>>> generator.writeStartArray();
>>>>> for (Object item in crate.items) {
>>>>> // Ooops! We don’t have a method to write an object without a key in
>>>>> SerializationContext
>>>>> // It should be something like this
>>>>> *context.serialize(item, generator); // This is a new method to add I
>>>>> was talking about*
>>>>> }
>>>>> generator.writeEnd();
>>>>>
>>>>>
>>>> Not sure if I followed everything (I have been busy with other things
>>>> lately), but IMO the context should not provide different methods for
>>>> arrays, objects etc. Only one that takes an object, a generator and
>>>> eventually a type (if we want to allow a user to say serialize object of
>>>> type B but using his super type A). One could pass to it arrays, lists,
>>>> pojos, primitives, whatever he wants and it will get serialized/deser using
>>>> the registered serializers for that type.
>>>> I hope I am not adding more confusion here…if you want some code
>>>> examples let me know.
>>>>
>>>>
>>>> Yes, I think we have some misunderstanding here. Below I copied our
>>>> latest version of SerializationContext interface to make it clear. As you
>>>> see there are no methods for arrays, lists, etc. The method I was talking
>>>> about above is marked bold.
>>>>
>>>> public interface SerializationContext {
>>>>
>>>> /**
>>>> * Serializes arbitrary object to JSON, using current {_at_link
>>>> javax.json.stream.JsonGenerator} instance.
>>>> *
>>>> * @param key JSON key name
>>>> * @param object object to serialize
>>>> * @param generator JSONP generator to serialize with
>>>> * @param <T> Type of serialized object
>>>> */
>>>> <T> void serialize(String key, T object, JsonGenerator generator);
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> * /** * Serializes arbitrary object to JSON, using current
>>>> {_at_link javax.json.stream.JsonGenerator} instance. * * @param
>>>> object object to serialize * @param generator JSONP generator to
>>>> serialize with * @param <T> Type of serialized object */ <T>
>>>> void serialize(T object, JsonGenerator generator);*
>>>>
>>>> /**
>>>> * Converts string value into provided type. String value has to be
>>>> single JSON value, not a part
>>>> * of a JSON document representing JSON object.
>>>> *
>>>> * @param obj object to convert to string
>>>> * @param generator JSONP generator to serialize with
>>>> * @param <T> type of object
>>>> *
>>>> * @return converted string value
>>>> * @throws javax.json.bind.JsonbException if conversion of given
>>>> type is not supported
>>>> */
>>>> <T> String convertDefault(T obj, JsonGenerator generator);
>>>> }
>>>>
>>>> Thanks,
>>>> Dmitry
>>>>
>>>>
>>>
>>
>>
>
>