jsr367-experts@jsonb-spec.java.net

[jsr367-experts] Re: [jsonb-spec users] Re: [30-GenericTypeSupport] Proposal

From: Romain Manni-Bucau <rmannibucau_at_tomitribe.com>
Date: Fri, 13 Mar 2015 12:50:12 +0100

Well that is for consistency of the api itself. In my opinion it is a quick
win plus auto documentation since the package will help to discover it. Why
looking in javax.enterprise for a javax.json* feature?

While we dont provide all possible implementations in the api I really see
it as positive.
Le 13 mars 2015 12:31, "Martin Grebac" <martin.grebac_at_oracle.com> a écrit :

> I don't think there's a need to focus on a specific library. JSON Binding
> will likely be mostly used not on its own but within scope of other apis
> and libraries. Within JavaEE e.g., either CDI or JAX-RS, both of them
> provide apis which can be used to provide portable solution.
> MartiNG
>
> On 13.03.15 12:18, Romain Manni-Bucau wrote:
>
>>
>> Well didnt want to enter into this - just dont want a troll - but guava
>> can break apps in some cases - common enough to be taken into account - so
>> guava is not a solution - and i skip other drawbacks it has like its size.
>>
>> Let provide a real solution since it is trivial here, no? For other cases
>> guava or any other implementation is great.
>>
>> Le 13 mars 2015 12:13, "Eugen Cepoi" <cepoi.eugen_at_gmail.com <mailto:
>> cepoi.eugen_at_gmail.com>> a écrit :
>>
>> Hey Romain,
>>
>> 2015-03-13 11:38 GMT+01:00 Romain Manni-Bucau
>> <rmannibucau_at_tomitribe.com <mailto:rmannibucau_at_tomitribe.com>>:
>>
>> Answered inline
>>
>> Le 13 mars 2015 08:28, "Inderjeet Singh"
>> <inder_at_alumni.stanford.edu <mailto:inder_at_alumni.stanford.edu>>
>> a écrit :
>> >
>> > Don't force them, but let them use the library of their
>> choice (Guava, Johnzon or any other) to create a Type object.
>> >
>>
>> This is the original issue. For advanced cases (N levels of
>> generics with N > 1) it is fine but for common cases (N =1) it
>> sounds like a failure. Said otherwise why using an api which
>> needs another one? Just use the complete one.
>>
>> I understand your point but don't feel like it is a big issue.
>> Anyway everyone uses guava...
>>
>> > Using a constructed Type is an advanced use-case anyway. For
>> example, with Gson, a majority
>> of use-cases get handled without constructing a type ever.
>> >
>>
>> Not fully agree. List and Map are super common (just think to
>> crud). We can't rely on wrappers as for jaxb for json - just
>> check how many people get rid of jettison for alternatives
>> cause of it. Just makes it not natural so parameterized type
>> are as common as classes for me.
>>
>>
>>
>> I changed my mind and support the use of Type + some doc that
>> explains to the users how to obtain it (with Guava probably). It
>> looks like the easiest solution :) As Inder stated, if we had a
>> TypeToken equivalent impl in std jdk it would be great, but as we
>> don't...
>>
>> Cheers,
>> Eugen
>>
>>
>> > Inder
>> >
>> > On Thu, Mar 12, 2015 at 11:49 PM, Romain Manni-Bucau
>> <rmannibucau_at_gmail.com <mailto:rmannibucau_at_gmail.com>> wrote:
>> >>
>> >> We can't force a user to use a lib - or means the spec is
>> not usable.
>> >>
>> >> Can be as simple as providing an implementation like
>> JohnzonParameterizedType [1] which is trivial but solves this
>> issue for most of cases - and several of remzining ones can be
>> illegal (type variable etc).
>> >>
>> >> [1]
>> https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.
>> git;a=blob;f=johnzon-mapper/src/main/java/org/apache/
>> johnzon/mapper/reflection/JohnzonParameterizedType.java;h=
>> 479268e451b88de3851dce48a97a0f6d29ca3b79;hb=
>> dcc3a2c2a96d095251328740c03ebc0c053077c6
>> >>
>> >> - Romain
>> >>
>> >> Le 13 mars 2015 07:38, "Inderjeet Singh"
>> <inder_at_alumni.stanford.edu <mailto:inder_at_alumni.stanford.edu>>
>> a écrit :
>> >>
>> >>> My recommendation will be that this API shouldn't provide
>> any TypeLiteral.
>> >>> For the users who need that support, should use Guava in
>> conjunction with this.
>> >>>
>> >>> Inder
>> >>>
>> >>>
>> >>> On Thu, Mar 12, 2015 at 2:50 PM, Romain Manni-Bucau
>> <rmannibucau_at_tomitribe.com <mailto:rmannibucau_at_tomitribe.com>>
>> wrote:
>> >>>>
>> >>>> Hi
>> >>>>
>> >>>> Type is really powerful but has one drawback: it is not
>> working out of the box. This means we need to add a reflect
>> package with basic implementations of some types in the api to
>> make it a smooth api - at least ParameterizedType and maybe a
>> list/set/map ones cause it is very common. Next issue we could
>> hit is then we depend in the api of the jvm indirectly -
>> interfaces get new method with jvm versions sometimes so what
>> we can do is really bound to a jvm.
>> >>>>
>> >>>> That said i like the fact it avoids to introduce a new
>> api and yet another type literal but just some common helper
>> classes.
>> >>>>
>> >>>> - Romain
>> >>>>
>> >>>> Le 12 mars 2015 18:53, "Inderjeet Singh"
>> <inder_at_alumni.stanford.edu <mailto:inder_at_alumni.stanford.edu>>
>> a écrit :
>> >>>>
>> >>>>> For Gson, we started with Type for pretty much the same
>> reasons. Also because most developers are familiar with Type,
>> and TypeLiteral is a new/advanced concept.
>> >>>>>
>> >>>>> Gson uses <T> T fromJson(String, Type) to avoid the
>> need for casting. But it is unsafe, as you point out.
>> >>>>> In practice though, I have not seen it to be a problem.
>> >>>>>
>> >>>>> TypeLiteral are very useful in JSON conversion, so we
>> did end up adding it to Gson. Once we added it, I would have
>> liked to revise fromJson() methods to use TypeLiterals instead
>> of Type. But we couldn't do that for backward compatibility
>> reasons.
>> >>>>>
>> >>>>> So, the point really is that if TypeLiterals are going
>> to be added in a JSR, then it is better for JsonB to depend on
>> that JSR and use TypeLiterals.
>> >>>>>
>> >>>>> But if you can't depend on the TypeLiteral JSR (if any),
>> then go ahead and use Type. It works just fine.
>> >>>>>
>> >>>>> Inder
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Mar 12, 2015 at 9:51 AM, Eugen Cepoi
>> <cepoi.eugen_at_gmail.com <mailto:cepoi.eugen_at_gmail.com>> wrote:
>> >>>>>>
>> >>>>>> Hey Martin,
>> >>>>>>
>> >>>>>> 2015-03-12 17:21 GMT+01:00 Martin Vojtek
>> <voytoo_at_gmail.com <mailto:voytoo_at_gmail.com>>:
>> >>>>>>>
>> >>>>>>> Hi Experts,
>> >>>>>>>
>> >>>>>>> I would like to open discussion about Generic Type
>> Support in JSON Binding.
>> >>>>>>>
>> >>>>>>> The initial proposal is to add two methods to Jsonb
>> interface:
>> >>>>>>>
>> >>>>>>> public <T> T fromJson(String str,
>> java.lang.reflect.Type runtimeType) throws JsonbException;
>> >>>>>>>
>> >>>>>>> public String toJson(Object object,
>> java.lang.reflect.Type runtimeType) throws JsonbException;
>> >>>>>>>
>> >>>>>>> (and analogically other methods with different
>> input/output)
>> >>>>>>>
>> >>>>>>> Based on reviewing existing options, it does not
>> appear there is a single optimal option.
>> >>>>>>>
>> >>>>>>> Reasoning behind java.lang.reflect.Type.
>> >>>>>>>
>> >>>>>>> There are several ways how to deal with generics:
>> >>>>>>>
>> >>>>>>> 1. To use java.lang.reflect.Type
>> >>>>>>> 2. Use Type Literal (e.g. GenericType ...)
>> >>>>>>> 3. Use Generic Type Builder
>> >>>>>>>
>> >>>>>>> It would be a lot of unnecessary code to build Generic
>> Type Builder. And I think this should be not part of JSON Binding.
>> >>>>>>>
>> >>>>>>
>> >>>>>> I agree with you.
>> >>>>>>
>> >>>>>>>
>> >>>>>>> Type Literal may work in some cases, but generally it
>> doesn't work (in infinite cases). It is also not backed by
>> Java Language Specification and may not work in the future.
>> For example, Type Literal doesn't work when used with lambdas
>> or with some JVM languages different than Java.
>> >>>>>>
>> >>>>>>
>> >>>>>> I understand but I think that it works in most use
>> cases where it is needed. People use it to just deal with
>> basic generics (custom or std types).
>> >>>>>>
>> >>>>>>>
>> >>>>>>> I don't want to introduce yet another GenericType
>> class and to duplicate code with some other specifications.
>> >>>>>>
>> >>>>>>
>> >>>>>> I agree it is ugly :( would have been better if there
>> was a similar thing as TypeToken from guava in std java (even
>> if it is a hack in some way).
>> >>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Use of java.lang.reflect.Type seems like the best
>> choice from bad choices available. Integration with JAX-RS
>> will be flawless, it is upon the user to build
>> java.lang.reflect.Type (hopefully with the help of JSON
>> Binding implementation).
>> >>>>>>>
>> >>>>>>> User can use already available Type Literal classes
>> available in the Java ecosystem.
>> >>>>>>
>> >>>>>>
>> >>>>>> Good point and most people already use guava. Only
>> downside will be the untyped result of the fromJson.
>> >>>>>> Here we can avoid user cast by doing : <T> T
>> fromJson(String, Type), but it is definitely unsafe.
>> >>>>>>
>> >>>>>> Might be interesting to have Inderjeets feedback on how
>> it was when they were using type and TypeToken.
>> >>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Examples and pdf proposal are available at
>> >>>>>>>
>> >>>>>>>
>> https://java.net/projects/jsonb-spec/sources/git/
>> content/spec/spec.pdf?rev=da7db533076856699cec49a4eebd300b9f4a7230
>> >>>>>>>
>> >>>>>>>
>> https://github.com/json-binding/spec/blob/default_
>> mapping/examples/runtime/src/main/java/examples/mapping/
>> DefaultMappingGenerics.java
>> >>>>>>>
>> >>>>>>> Looking forward to your feedback.
>> >>>>>>>
>> >>>>>>> MartinV
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>
>> >
>>
>>
>>
> --
> Martin Grebac, SW Engineering Manager
> Oracle Czech, Prague
>
>