2015-03-13 19:59 GMT+01:00 Inderjeet Singh <inder_at_alumni.stanford.edu>:
>
>
> On Fri, Mar 13, 2015 at 10:56 AM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
> wrote:
>
>>
>>
>> 2015-03-13 18:43 GMT+01:00 Inderjeet Singh <inder_at_alumni.stanford.edu>:
>>
>>> I think fromJson(File) is unnecessary and should be removed.
>>> Even fromJson(InputStream) is supect, but I guess InputStreams are still
>>> all too common.
>>>
>>>
>> I think it is good to keep InputStream, most of the time we deal with
>> inputstream or byte arrays.
>>
> toJson(..., Appendable appendable) should be better than Writer().
>>>
>>
>> Hum, writer allows to write array of chars, obtaining a charsequence from
>> an array of chars would degrade impls don't you agree?
>>
>
> In Gson, we check if the Appendable is a Writer, if not, we wrap it with
> an AppendableWriter object.
> Internal implementation shouldn't pollute the API.
>
You make a point and any way people who use Writer will not suffer from any
performance loss. Ok why not.
>
> Get rid of toJson(..., writer), toJson(..., File) and toJson(...,
>>> OutputStream)
>>>
>>
>> File I don't care, but disagree for OS.
>>
>
> In Gson, we don't provide support for InputStream/OutputStream. Not have
> had a single person complain about it so far.
> new InputStreamReader(inputStream) works fine. Same goes for OutputStream.
>
When wrapping a byte array it starts to get worse. Often I see brilliant
code on SO where someone will take an inputstream and make a string of it
(with 20 LOC) in order to then use a json lib to parse it. I hope that by
providing this kind of methods it is more obvious that people can pass an
inputstream to the API. But it is true they can wrap it. In first versions
of Genson I followed the same logic and didn't provide methods for reading
from a stream, added it later.
>
> Why complicate Jsonb API with unnecessary clutter.
>
>
>
>>
>>> A powerful (and very useful) feature of Gson is custom type adapters.
>>> How will that be done in Jsonb.
>>>
>>
>> I guess it will be achieved via a similar mechanism as the type adapters
>> in JAXB?
>>
>
> Which annotation in Jaxb for that?
> In Gson, we cared a lot about a non-annotation way as well since classes
> in third-party libraries or JDK can't be annotated. What's your thought on
> that?
>
>
The annotation is XmlJavaTypeAdapter and the class doing the work is impls
of XmlAdapter.
I agree 100% with the third-party libs and annotations limitations. In
Genson I provide Converters (equivalent of Gsons TypeAdapters) but those
don't provide all the context you have with an annotation. Thus I also
added what I call a ContextualFactory where the user has access to some
stuff about the property (declaring class, prop name, etc). And some other
stuff like filtering and renaming with GensonBuilder.
This covers for the moment most classic use cases someone would want to
address when dealing with third party code.
Jackson uses some kind of mixins. I tried similar approaches but I am not
satisfied of them yet and hesitate between removing it from the API or
improving it...
Eugen
> Inder
>
>
>