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 <mailto: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?
>
>> 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
>> <mailto: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 <mailto: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
>>
>>
>>
>
>