2015-03-13 18:57 GMT+01:00 Romain MB <rmannibucau_at_tomitribe.com>:
> 2015-03-13 18:50 GMT+01:00 Inderjeet Singh <inder_at_alumni.stanford.edu>:
> >
> >
> > On Fri, Mar 13, 2015 at 10:32 AM, Romain Manni-Bucau
> > <rmannibucau_at_tomitribe.com> wrote:
> >>
> >> Hmm, maybe I missed something:
> >>
> >> 1) Map has the same issue as well (serializing it as an object results
> to
> >> something unpredicatable where it is actually)
> >
> >
> > Map may have the same issue but in practice I don't see APIs using Map as
> > the return type. Instead people use a regular class. OTOH, Lists are
> common
> > because often REST APIs return collections of resources.
> >
> >
>
> Well saw it regularly on cloud solutions and devoxx API at least.
>
> >
> >>
> >> 2) forcing developpers to use an array is not an option I fear (will
> >> result in very very bad pattern forcing too much allocations and
> convertion
> >> and will create a not fluent/smooth API)
> >
> >
> > Not sure about the "very very bad" part. Arrays.asList() is supposed to
> be
> > an efficient wrapper around arrays.
> > I am presenting it as a work around for the developer who doesn't want to
> > deal with type creation.
> >
> >>
> >> Clearly for me the question here is: do we align on what people do or do
> >> we force them to do something else?
> >
> >
> > Developers use multiple libraries all the time. It is not a burden to ask
> > them to use an alternate facility for Type creation, especially since it
> is
> > an advanced case.
> >
>
> This is true but makes the API hard to use out of the box and
> libraries writers forced to fork always and always the same classes.
>
Libs that will impl this spec probably already have their own TypeToken
impl and all the stuff that goes with it.
The only clean solution I could think here is to have something similar
provided with the jdk. Re-implementing it in each spec that needs it seems
wrong :(
>
> > Inder
> >
> >
> >
> >
> >>
> >>
> >>
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >> 2015-03-13 18:27 GMT+01:00 Inderjeet Singh <inder_at_alumni.stanford.edu>:
> >>>
> >>> I personally have moved away from Guava, it is too bloated, and
> >>> unnecessarily complex from my point of view.
> >>> However, I do pick and choose classes from it all the time. In Gson, we
> >>> copied Guava's TypeToken. I expect other developers will do the same.
> They
> >>> will figure out their preferred way of creating Types.
> >>>
> >>> Regarding your N=1 point: Note that this is an issue ONLY if you are
> >>> deserializing into a top-level object which is List or Map. If the
> List or
> >>> Maps were fields within an object, everything works fine.
> >>> Map is usually not an issue either (since Maps are similar to Objects),
> >>> it is the List<> which is more common and problematic. However,
> >>> deserializing to an array type will work. And then the developer can
> use
> >>> Arrays.asList() to get back the list they want.
> >>>
> >>> So, I think it is still a good idea to leave the TypeToken out of the
> >>> API, and let the developers deal with it in alternate ways.
> >>>
> >>> Inder
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Mar 13, 2015 at 4:50 AM, Romain Manni-Bucau
> >>> <rmannibucau_at_tomitribe.com> wrote:
> >>>>
> >>>> 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
> >>>>>
> >>>
> >>
> >
>