Hi Dmitry,
Thought to it but then for JSON the To is limited (bool, number,
string, ... but not MyType as in XML). Said otherwise and a bit like
ini java 8 we could get NumberAdapter, BoolAdapter etc..
The goal? Avoid a Adapter<User, Person> which doesnt mean anything for
json IMHO.
All could be marker by Adapter interface but without any generics to
avoid previous pitfall.
wdyt?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-12-06 11:20 GMT+01:00 Dmitry Kornilov <dmitry.kornilov_at_oracle.com>:
> Hi Romain,
>
> I fully agree. I see it more like this:
>
> Adapter<From, To> {
> To convert(From value);
> From convertBack(To value);
> }
>
> I think that converting to a class (To) Jsonb engine knows how to process is better than converting to a pure Json string. Where is also an ability of fine tuning by putting @JsonbXXX annotations on “To”.
>
> Thanks,
> Dmitry
>
>> On 06 Dec 2015, at 10:54, Romain Manni-Bucau <rmannibucau_at_tomitribe.com> wrote:
>>
>> Hi guys,
>>
>> reviewing the ED i realised the adapter API we have ATM is hard to use
>> in common case cause:
>>
>> - you are forced to specify the type in unintuitive methods (Type or
>> Class + it is redundant with generics)
>> - it is too XML and not JSON friendly enough IMO. Do we need it for a
>> 1.0 or a Type <-> String is enough? (other types have @JsonbXXX for
>> the parsing/serializing)
>>
>> cant we just get: Adapter<Type> { Type from(String); String to(Type); }?
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>