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