jsr367-experts@jsonb-spec.java.net

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

From: Romain Manni-Bucau <rmannibucau_at_tomitribe.com>
Date: Wed, 11 May 2016 11:18:40 +0200

I was more thinking about jsonbconfig adapter/serializers which can be
reused transparently there. Annotations can only be respected for the
object passed through the serializer but it is fine and what would be
expected IMO.

I'm not sure I see how an adapter solves the serializer issue but code
being 10 lines we can think of it later if you all think it is useless for
now. Feature is there, just thought API could be smoother but not a blocker
for now.


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau

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

>
>
> On 05/10/2016 04:30 PM, Romain Manni-Bucau wrote:
>
>
> 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>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.
>
> How about user declaring adapter generic to <MyPojo, JsonObject >? Would
> it supplement seamlessly such an abstract deserializer? Parser would be
> advanced anyway in deserializer beyond its context, so no need for
> reference in such case.
>
>
>
>> 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://www.tomitribe.com
>>> <http://rmannibucau.wordpress.com>http://rmannibucau.wordpress.com
>>> <https://github.com/rmannibucau>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
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>