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