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.
> 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
>>>>>
>>>
>>
>