Le 13 mars 2015 19:07, "Eugen Cepoi" <cepoi.eugen_at_gmail.com> a écrit :
>
>
> 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 :(
>
I agree it would help but I don't find it too wrong to not do it while it
is a small amount of code. Allows a better decoupling of specifications and
is surely the best we can do for now.
Side note: also what is done until now in all specs AFAIK.
>>
>>
>> > 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
>> >>>>>
>> >>>
>> >>
>> >
>
>