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.
> 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.
Inder
>
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*
> <http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau
> <http://fr.linkedin.com/in/rmannibucau>*
> *Github: https://github.com/rmannibucau <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
>>>>
>>>>
>>
>