Javabeans has @ConstructorProperties which fits the need IMO.
Immutability is another topic we should be compliant to but not force IMO -
dont want to go to far in this thread on it since it is close to religion
since technically there is no strong reason to enforce it.
Le 11 avr. 2015 19:54, "Inderjeet Singh" <inder_at_alumni.stanford.edu> a
écrit :
>
> Agree with "public final fields" being an acceptable practice.
>
> IMO, Encapsulation is about programmatic access to objects, not about its
serialized form.
> What goes on the wire is data, which is best represented by fields. I
agree that fields are an internal representation and may not accurately
represent what you want on wire.
> In practice though, it rarely is a problem. For those rare cases, Custom
Type adapters fit the bill.
>
> In Genson, how do you invoke the constructor while passing arguments
since the parameter names are not retained at runtime. How do you figure
out which JSON field maps to which parameter?
>
> Inder
>
>
>
>
> On Sat, Apr 11, 2015 at 10:23 AM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
wrote:
>>
>>
>>
>> 2015-04-11 18:28 GMT+02:00 Inderjeet Singh <inder_at_alumni.stanford.edu>:
>>>
>>> I stand by my assertions on good coding practices and there is plenty
of literature to support them. Briefly,
>>> 1. Public fields break encapsulation so should be avoided.
>>> 2. Immutability enhances thread-safety, and avoid unintended
side-effects (you can safely return internal objects in methods without
worrying about someone modifying them).
>>>
>>> However, I agree that there are no absolutes and mutability has its
place. That is why these are good practices, not requirements.
>>>
>>> My problem is when a technology makes it hard or impossible for me to
follow these practices. For example, JPA forces me to make my fields
mutable. I don't like that a single bit.
>>> On the contrary, Gson encourages you to define fields as private final,
thus enabling encapsulation and immutability.
>>
>>
>> Serializing private fields is breaking this encapsulation.
>> I think having public final fields is fine and don't feel it as a bad
practice, or at least it depends on the use case. Anyway until people can
configure their Jsonb instance to support whatever they like, I am fine
with it.
>>
>> About immutability, the best solution IMO is to support constructors
with arguments (not generating ctrs via Unsafe or passing null/default
values or expecting people to write custom code). That's how I am trying to
encourage immutability in Genson - for now it works pretty well.
>>
>> Eugen
>>
>>>
>>> I consider that to be a better design. JSR-367 should follow similar
principles.
>>>
>>>
>>> Inder
>>>
>>>
>>>
>>> On Sat, Apr 11, 2015 at 7:55 AM, Romain Manni-Bucau <
rmannibucau_at_tomitribe.com> wrote:
>>>>
>>>>
>>>> Le 11 avr. 2015 16:24, "Inderjeet Singh" <inder_at_alumni.stanford.edu> a
écrit :
>>>> >
>>>> > The design should encourage great coding practices. Supporting
public fields will do the opposite.
>>>> >
>>>>
>>>> Yes and no. It makes sense in some cases. I'd let it up to users and
their programming model.
>>>>
>>>> > Another great coding practice is making classes immutable. Which
means no setters either.
>>>> >
>>>>
>>>> Why? This is wrong in the absolute but right in some context like
message passing pattern usage. Someone could say you immutable is bad
cause of memory profile it mandates.
>>>>
>>>> Here I would just align on java ie supporting accessors AND
constructor usage (being aligned on javabeans let user do what he wants
without forcing one of both patterns)
>>>>
>>>> > Inder
>>>> >
>>>> >
>>>> >
>>>> > On Sat, Apr 11, 2015 at 4:16 AM, Martin Vojtek <voytoo_at_gmail.com>
wrote:
>>>> >>
>>>> >> Alright, I don't see big enthusiasm for the idea of private fields
included in default mapping :)
>>>> >>
>>>> >> So, the second proposal is as follows:
>>>> >>
>>>> >> - support public fields
>>>> >> - support get/set
>>>> >>
>>>> >> If there is get/set, use it.
>>>> >> If there is just public field, use it.
>>>> >> If there is just get/set and no field, use get/set.
>>>> >>
>>>> >> Other options should be configurable.
>>>> >>
>>>> >> MartinV
>>>> >>
>>>> >> On Sat, Apr 11, 2015 at 11:17 AM, Romain MB <
rmannibucau_at_tomitribe.com> wrote:
>>>> >>>
>>>> >>> While field visibility can be customized by method it works - ie
private getter hides fields during ser - but does it make sense to support
fields not accessible by code at all by default? I am not convinced. Means
design is broken even if I understand it is technical only objects. Think
staying aligned on java is not that bad.
>>>> >>>
>>>> >>> Le 10 avr. 2015 22:43, "Inderjeet Singh" <inder_at_alumni.stanford.edu>
a écrit :
>>>> >>>>
>>>> >>>> In Gson, we agonized over this issue periodically.
>>>> >>>>
>>>> >>>> In the end, I think our current approach works. Just support
fields (public or private), and ignore methods. The developers should use
custom type adapters for anything more complicated.
>>>> >>>>
>>>> >>>> Inder
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> On Fri, Apr 10, 2015 at 12:33 PM, Romain Manni-Bucau <
rmannibucau_at_tomitribe.com> wrote:
>>>> >>>>>
>>>> >>>>> Well issue supporting private fields by default is you dont
expose correct payload (API for REST endpoint!!) if you need any internal
variable which is super risky compared to have to activate field visibility
manually.
>>>> >>>>>
>>>> >>>>> That said I am happy while it is customizable.
>>>> >>>>>
>>>> >>>>> Le 10 avr. 2015 20:38, "Eugen Cepoi" <cepoi.eugen_at_gmail.com> a
écrit :
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> 2015-04-10 20:11 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>>> >>>>>>>
>>>> >>>>>>> Interesting point of view. I was thinking mainly about deser
scenario and no mixin.
>>>> >>>>>>>
>>>> >>>>>>> I still see public fields more like a not so good design
decision (instead of public contract).
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> Depends, public final fields look good to me (only if final).
Esp. when it is supposed to exclusively hold "public" data.
>>>> >>>>>> But I guess it is more of a religion if you are alergic to
get/set or not - as you can guess I am :)
>>>> >>>>>>
>>>> >>>>>>>
>>>> >>>>>>>
>>>> >>>>>>> I think there are two regular cases:
>>>> >>>>>>>
>>>> >>>>>>> 1. class with all fields private with get/set methods
>>>> >>>>>>>
>>>> >>>>>>> 2. class with just non public fields
>>>> >>>>>>>
>>>> >>>>>>> Other not so good cases (by design) :)
>>>> >>>>>>>
>>>> >>>>>>> - class with all fields public (no get/set)
>>>> >>>>>>>
>>>> >>>>>>> - class with mix of fields and get/set methods.
>>>> >>>>>>>
>>>> >>>>>>> Anyway, I still think it is better to support all these cases.
If user doesn't want some property to be serialized into json, he could put
annotation or transient keyword on the given field or set/get method.
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>>> Yeah sure but it could be the other way too, only public +
annotate what else you want to include or configure your instance of Jsonb
to do so.
>>>> >>>>>> Anyway, if there is a option to configure visibility in Jsonb
(without annotations) I am fine with it.
>>>> >>>>>>
>>>> >>>>>> Eugen
>>>> >>>>>>
>>>> >>>>>>>
>>>> >>>>>>> What do others think about support of private fields by
default?
>>>> >>>>>>>
>>>> >>>>>>>
>>>> >>>>>>> MartinV
>>>> >>>>>>>
>>>> >>>>>>>
>>>> >>>>>>> On Fri, Apr 10, 2015 at 7:11 PM, Eugen Cepoi <
cepoi.eugen_at_gmail.com> wrote:
>>>> >>>>>>>>
>>>> >>>>>>>> Just some insights about mixing by default public and
private...
>>>> >>>>>>>>
>>>> >>>>>>>> 2015-04-08 20:31 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>>> >>>>>>>>>
>>>> >>>>>>>>> I vote for the following (default mapping):
>>>> >>>>>>>>>
>>>> >>>>>>>>> - support private fields (private fields are good habit in
Java)
>>>> >>>>>>>>
>>>> >>>>>>>>
>>>> >>>>>>>> Doing ser/de by using private fields when at the same time
one uses public contract can be source of problems.
>>>> >>>>>>>>
>>>> >>>>>>>> As a user
>>>> >>>>>>>> - I want to ser/de all the private fields when I am doing
some RPC because on the other side I will use this technical low level
representation to provide the same contract other the private data (in this
situation I just don't want the lib to look at methods, but take all the
private fields except transient/static).
>>>> >>>>>>>>
>>>> >>>>>>>> - I want to ser/de using public methods and fields to expose
a kind of API/public data. In this situation I don't want the lib to pick
my private fields because they are the way I internally represent stuff,
the consumer doesn't have to know about that.
>>>> >>>>>>>>
>>>> >>>>>>>> That's also the logic I followed when making Genson. I think
exposing both by default is wrong...(but one can still use the annotations
from a field and apply them to a method, just not ser/de protected/private
stuff by default)
>>>> >>>>>>>>
>>>> >>>>>>>>
>>>> >>>>>>>>>
>>>> >>>>>>>>> - support get/set
>>>> >>>>>>>>>
>>>> >>>>>>>>> If there is get/set, use it.
>>>> >>>>>>>>> If there is just field, use it.
>>>> >>>>>>>>> If there is just get/set and no field, use get/set.
>>>> >>>>>>>>>
>>>> >>>>>>>>> Other options should be configurable.
>>>> >>>>>>>>>
>>>> >>>>>>>>> MartinV
>>>> >>>>>>>>>
>>>> >>>>>>>>> On Wed, Apr 8, 2015 at 11:25 AM, Eugen Cepoi <
cepoi.eugen_at_gmail.com> wrote:
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> 2015-04-08 10:17 GMT+02:00 Hendrik Dev <
hendrikdev22_at_gmail.com>:
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> (sorry, wrong list)
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> ---------- Forwarded message ----------
>>>> >>>>>>>>>>> From: Hendrik Dev <hendrikdev22_at_gmail.com>
>>>> >>>>>>>>>>> Date: Wed, Apr 8, 2015 at 10:16 AM
>>>> >>>>>>>>>>> Subject: Re: [jsonb-spec users] Re: [jsr367-experts] Re:
Re: Re:
>>>> >>>>>>>>>>> [30-GenericTypeSupport] Proposal
>>>> >>>>>>>>>>> To: users_at_jsonb-spec.java.net
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> I would say: Support all variants (fields and/or
(getters/setters))
>>>> >>>>>>>>>>> including private fields and by default use only
getter/setters (and
>>>> >>>>>>>>>>> no fields). Thats what the most users would expect AFAIK.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> In genson I include public fields by default, it sounds
natural to me as the public methods and fields define the "exposed"
contract about the data. Then users can customize it as they want.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> Dont know if just getters or just setters is really
useful, IMHO it
>>>> >>>>>>>>>>> complicates the thing without adding real value (can be
done with
>>>> >>>>>>>>>>> @Ignore if really necessary)
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Agreed.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> We do this in Johnzon via AccessMode
>>>> >>>>>>>>>>> (
https://github.com/apache/incubator-johnzon/blob/master/johnzon-mapper/src/main/java/org/apache/johnzon/mapper/access/AccessMode.java
)
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> Thanks
>>>> >>>>>>>>>>> Hendrik
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> On Wed, Apr 8, 2015 at 9:33 AM, Oleg Tsal-Tsalko <
oleg.tsalko_at_gmail.com> wrote:
>>>> >>>>>>>>>>> > Hi guys,
>>>> >>>>>>>>>>> >
>>>> >>>>>>>>>>> > My vote (if it counts) is to definitely support by
default all variants
>>>> >>>>>>>>>>> > (e.g. fields/getters/setters) in all combinations (e.g.
getters+setters or
>>>> >>>>>>>>>>> > just getters or just setters even if it silly usage from
user perspective) +
>>>> >>>>>>>>>>> > with private access.
>>>> >>>>>>>>>>> > The only thing we need to decide on relative priorities
to resolve ties if
>>>> >>>>>>>>>>> > any.
>>>> >>>>>>>>>>> >
>>>> >>>>>>>>>>> > Thank you,
>>>> >>>>>>>>>>> > Oleg
>>>> >>>>>>>>>>> >
>>>> >>>>>>>>>>> >
>>>> >>>>>>>>>>> > 2015-04-07 22:16 GMT+03:00 Romain MB <
rmannibucau_at_tomitribe.com>:
>>>> >>>>>>>>>>> >>
>>>> >>>>>>>>>>> >>
>>>> >>>>>>>>>>> >> Le 7 avr. 2015 21:07, "Eugen Cepoi" <
cepoi.eugen_at_gmail.com> a écrit :
>>>> >>>>>>>>>>> >> >
>>>> >>>>>>>>>>> >> >
>>>> >>>>>>>>>>> >> >
>>>> >>>>>>>>>>> >> > 2015-04-07 20:48 GMT+02:00 Romain MB <
rmannibucau_at_tomitribe.com>:
>>>> >>>>>>>>>>> >> >>
>>>> >>>>>>>>>>> >> >>
>>>> >>>>>>>>>>> >> >> Le 7 avr. 2015 20:27, "Eugen Cepoi" <
cepoi.eugen_at_gmail.com> a écrit :
>>>> >>>>>>>>>>> >> >> >
>>>> >>>>>>>>>>> >> >> >
>>>> >>>>>>>>>>> >> >> >
>>>> >>>>>>>>>>> >> >> > 2015-04-07 20:05 GMT+02:00 Romain MB <
rmannibucau_at_tomitribe.com>:
>>>> >>>>>>>>>>> >> >> >>
>>>> >>>>>>>>>>> >> >> >> Hi
>>>> >>>>>>>>>>> >> >> >>
>>>> >>>>>>>>>>> >> >> >> This topic is very interesting but I think we
should just align by
>>>> >>>>>>>>>>> >> >> >> default on javabeans and allow a configuration
(+api) for other usages which
>>>> >>>>>>>>>>> >> >> >> are widely spread over applications.
>>>> >>>>>>>>>>> >> >> >>
>>>> >>>>>>>>>>> >> >> >> So I propose:
>>>> >>>>>>>>>>> >> >> >>
>>>> >>>>>>>>>>> >> >> >> - default: getter/setter only, no field check at
all,
>>>> >>>>>>>>>>> >> >> >
>>>> >>>>>>>>>>> >> >> >
>>>> >>>>>>>>>>> >> >> > I think it is more friendly to have public methods
and fields (for
>>>> >>>>>>>>>>> >> >> > example if one has a immutable pojo with all
fields public).
>>>> >>>>>>>>>>> >> >> >
>>>> >>>>>>>>>>> >> >>
>>>> >>>>>>>>>>> >> >> Fair enough
>>>> >>>>>>>>>>> >> >>
>>>> >>>>>>>>>>> >> >> >>
>>>> >>>>>>>>>>> >> >> >> support of addX for collections and maybe getter
in write mode as in
>>>> >>>>>>>>>>> >> >> >> jaxb.
>>>> >>>>>>>>>>> >> >> >
>>>> >>>>>>>>>>> >> >> > I am hesitating for addX not sure I like it...
>>>> >>>>>>>>>>> >> >> > What is getter in write mode?
>>>> >>>>>>>>>>> >> >> >
>>>> >>>>>>>>>>> >> >>
>>>> >>>>>>>>>>> >> >> getMyCollection().add(xx) instead of just using
setMyCollection(col)
>>>> >>>>>>>>>>> >> >
>>>> >>>>>>>>>>> >> >
>>>> >>>>>>>>>>> >> > Ok I understand better what you mean. I can see only
2 use cases for
>>>> >>>>>>>>>>> >> > this: when adding stuff to the list the pojo is doing
something (increment a
>>>> >>>>>>>>>>> >> > counter for example) or updating an existing instance
(kind of merge).
>>>> >>>>>>>>>>> >>
>>>> >>>>>>>>>>> >> Well jaxb does it cause setColl makes the API not that
natural I think.
>>>> >>>>>>>>>>> >>
>>>> >>>>>>>>>>> >> > I don't think we provide any merge solution now so
point 2 is excluded
>>>> >>>>>>>>>>> >> > and 1 is still valid even if I don't like it :)
>>>> >>>>>>>>>>> >> >
>>>> >>>>>>>>>>> >>
>>>> >>>>>>>>>>> >> +0, being aligned on other specs would be nice as well.
JPA started
>>>> >>>>>>>>>>> >> without merges then added it to make it smooth for
users. When we dont know
>>>> >>>>>>>>>>> >> or there is a conflict it is easy to fail - like jaxb.
>>>> >>>>>>>>>>> >>
>>>> >>>>>>>>>>> >> >
>>>> >>>>>>>>>>> >> > Eugen
>>>> >>>>>>>>>>> >> >>
>>>> >>>>>>>>>>> >> >> >>
>>>> >>>>>>>>>>> >> >> >> I like it cause it really exposes an API and not
internals.
>>>> >>>>>>>>>>> >> >> >> - a shortcut in config api to use fields (either
only or in
>>>> >>>>>>>>>>> >> >> >> cumulative mode) - this is too common to not be
handled and the default in
>>>> >>>>>>>>>>> >> >> >> most ee API (JPA for instance)
>>>> >>>>>>>>>>> >> >> >> - add in API an abstraction for it for advanced
mode and evolutions
>>>> >>>>>>>>>>> >> >> >> (Accessor, and AccessorFinder - I am not happy of
the naming but was to
>>>> >>>>>>>>>>> >> >> >> share the idea). It would allow to add processor
on the accessors to filter
>>>> >>>>>>>>>>> >> >> >> or remap them pretty easily. It makes trivial
remapping, version and
>>>> >>>>>>>>>>> >> >> >> blacklist handling for instance.
>>>> >>>>>>>>>>> >> >> >>
>>>> >>>>>>>>>>> >> >> >> Le 7 avr. 2015 19:57, "Martin Vojtek" <
voytoo_at_gmail.com> a écrit :
>>>> >>>>>>>>>>> >> >> >>>
>>>> >>>>>>>>>>> >> >> >>> It would be great to hear opinions from others
on this topic.
>>>> >>>>>>>>>>> >> >> >>>
>>>> >>>>>>>>>>> >> >> >>> Current JSON-B proposal is to by default
ser/deser only fields
>>>> >>>>>>>>>>> >> >> >>> where field is present. Specifically, if there
is field and set/get method,
>>>> >>>>>>>>>>> >> >> >>> set/get method is used. If there is not set/get
method, field is used. If
>>>> >>>>>>>>>>> >> >> >>> there is no field, but get/set method, it is not
used (JSON-B will not
>>>> >>>>>>>>>>> >> >> >>> consider this property). This behavior should be
customizable. Maybe it is
>>>> >>>>>>>>>>> >> >> >>> too restrictive and if there is getter and no
field, getter should be used.
>>>> >>>>>>>>>>> >> >> >>> What if there are methods not intended to be
getters? What if there is
>>>> >>>>>>>>>>> >> >> >>> method isValue and getValue?
>>>> >>>>>>>>>>> >> >> >>>
>>>> >>>>>>>>>>> >> >> >>> For properties that are being renamed ... I can
imagine use of
>>>> >>>>>>>>>>> >> >> >>> annotations.
>>>> >>>>>>>>>>> >> >> >>>
>>>> >>>>>>>>>>> >> >> >>> MartinV
>>>> >>>>>>>>>>> >> >> >>>
>>>> >>>>>>>>>>> >> >> >>> On Tue, Apr 7, 2015 at 4:27 PM, Eugen Cepoi <
cepoi.eugen_at_gmail.com>
>>>> >>>>>>>>>>> >> >> >>> wrote:
>>>> >>>>>>>>>>> >> >> >>>>
>>>> >>>>>>>>>>> >> >> >>>> Oh, yes, in fact this is something I did on
purpose for a couple
>>>> >>>>>>>>>>> >> >> >>>> of reasons. One of them is to allow people to
ser types based on some
>>>> >>>>>>>>>>> >> >> >>>> "parent type". For example if a class
implements several interfaces and we
>>>> >>>>>>>>>>> >> >> >>>> want to serialize using only one "aspect" of
the instance.
>>>> >>>>>>>>>>> >> >> >>>> The other reasons are more opinionated :)
>>>> >>>>>>>>>>> >> >> >>>>
>>>> >>>>>>>>>>> >> >> >>>> So in JSONB how do you see things, would we ser
only properties
>>>> >>>>>>>>>>> >> >> >>>> that have a field+get+set? I would prefer not
or at least provide a config
>>>> >>>>>>>>>>> >> >> >>>> for it.
>>>> >>>>>>>>>>> >> >> >>>>
>>>> >>>>>>>>>>> >> >> >>>> However something that is a bit similar, from
what I've seen,
>>>> >>>>>>>>>>> >> >> >>>> merging annotations from field/get/set is the
good way to go. Initially I
>>>> >>>>>>>>>>> >> >> >>>> thought it would be better to decouple ser from
deser aspect. But in the end
>>>> >>>>>>>>>>> >> >> >>>> I found that from an usage point of view,
people expect that annotations
>>>> >>>>>>>>>>> >> >> >>>> that have been put on the field are being used
also for get and set. The
>>>> >>>>>>>>>>> >> >> >>>> issue with this is how would one handle
properties that are being renamed? I
>>>> >>>>>>>>>>> >> >> >>>> am quite interested in others opinion on this
as I couldn't make my mind yet
>>>> >>>>>>>>>>> >> >> >>>> :)
>>>> >>>>>>>>>>> >> >> >>>>
>>>> >>>>>>>>>>> >> >> >>>> Thanks!
>>>> >>>>>>>>>>> >> >> >>>> Eugen
>>>> >>>>>>>>>>> >> >> >>>>
>>>> >>>>>>>>>>> >> >> >>>> 2015-04-07 16:00 GMT+02:00 Martin Vojtek <
voytoo_at_gmail.com>:
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>> The example I was thinking about is following:
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>> interface FunctionalInterface<T> {
>>>> >>>>>>>>>>> >> >> >>>>> public T getValue();
>>>> >>>>>>>>>>> >> >> >>>>> }
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>> Genson:
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>> public void test() {
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>> FunctionalInterface<String> myFunction =
() -> {return
>>>> >>>>>>>>>>> >> >> >>>>> "value1";};
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>> assertEquals("{\"value\":\"value1\"}",
>>>> >>>>>>>>>>> >> >> >>>>> genson.serialize(myFunction));
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>> }
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>> Proposed JSON-B:
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>> FunctionalInterface<String> myFunction = () ->
{return
>>>> >>>>>>>>>>> >> >> >>>>> "value1";};
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>> assertEquals("{}", jsonb.toJson(myFunction));
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>> The difference is in handling getters when
there is no field.
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>> MartinV
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>> On Mon, Apr 6, 2015 at 11:22 PM, Eugen Cepoi
>>>> >>>>>>>>>>> >> >> >>>>> <cepoi.eugen_at_gmail.com> wrote:
>>>> >>>>>>>>>>> >> >> >>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>> 2015-04-06 22:47 GMT+02:00 Martin Vojtek <
voytoo_at_gmail.com>:
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>> Hi,
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>> response inlined.
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>> Thanks,
>>>> >>>>>>>>>>> >> >> >>>>>>> Martin
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>> On Sun, Apr 5, 2015 at 5:57 PM, Oleg
Tsal-Tsalko
>>>> >>>>>>>>>>> >> >> >>>>>>> <oleg.tsalko_at_gmail.com> wrote:
>>>> >>>>>>>>>>> >> >> >>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>> Hi guys,
>>>> >>>>>>>>>>> >> >> >>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>> Feedback on generic mapping serialization
examples:
>>>> >>>>>>>>>>> >> >> >>>>>>>> 1) Why there are no examples of actual
usage of proposed
>>>> >>>>>>>>>>> >> >> >>>>>>>> Jsonb#toJson(Object, Type) method?
>>>> >>>>>>>>>>> >> >> >>>>>>>> I assume these examples should justify
usage of this advanced
>>>> >>>>>>>>>>> >> >> >>>>>>>> method in those special/tricky cases where
Jsonb#toJson(Object) method is
>>>> >>>>>>>>>>> >> >> >>>>>>>> not enough.
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>> Will add example:
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>> List<java.util.Optional<String>> expected =
>>>> >>>>>>>>>>> >> >> >>>>>>> Arrays.asList(Optional.empty(),
Optional.ofNullable("first"),
>>>> >>>>>>>>>>> >> >> >>>>>>> Optional.of("second"));
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>> String json = toJson(expected,
>>>> >>>>>>>>>>> >> >> >>>>>>>
DefaultMappingGenerics.class.getField("listOfOptionalStringField").getGenericType());
>>>> >>>>>>>>>>> >> >> >>>>>>>
assertEquals("[null,\"first\",\"second\"]",json);
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>> 2) Probably it was missed by me but are we
going to support
>>>> >>>>>>>>>>> >> >> >>>>>>>> serialization of anonymous
interfaces/classes implementations at all?
>>>> >>>>>>>>>>> >> >> >>>>>>>> As an example:
>>>> >>>>>>>>>>> >> >> >>>>>>>> myFunction = new
FunctionalInterface<String>() {
>>>> >>>>>>>>>>> >> >> >>>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>>> private String value = "initValue";
>>>> >>>>>>>>>>> >> >> >>>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>>> @Override public String getValue() {
>>>> >>>>>>>>>>> >> >> >>>>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>>>> return value;
>>>> >>>>>>>>>>> >> >> >>>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>>> }
>>>> >>>>>>>>>>> >> >> >>>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>>> public void setValue(String value) {
>>>> >>>>>>>>>>> >> >> >>>>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>>>> this.value = value;
>>>> >>>>>>>>>>> >> >> >>>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>>> }
>>>> >>>>>>>>>>> >> >> >>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>> };
>>>> >>>>>>>>>>> >> >> >>>>>>>> assertEquals("{\"value\":\"initValue\"}",
>>>> >>>>>>>>>>> >> >> >>>>>>>> jsonb.toJson(myFunction));
>>>> >>>>>>>>>>> >> >> >>>>>>>> It doesn't look like valid scenarios to
support.
>>>> >>>>>>>>>>> >> >> >>>>>>>> AFAIK, Gson lib doesn't support this...
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>> Don't see reason why it is not valid
scenario.
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>> Genson supports it (with different result in
some cases as
>>>> >>>>>>>>>>> >> >> >>>>>>> proposed JSON-B) :)
>>>> >>>>>>>>>>> >> >> >>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>> Heh looks like you had an in depth look at it
:) In what
>>>> >>>>>>>>>>> >> >> >>>>>> situation did it produce different or
undexpected results?
>>>> >>>>>>>>>>> >> >> >>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>> I added it because the effort to support it
was not so important
>>>> >>>>>>>>>>> >> >> >>>>>> and this can be of some use. But this looks
like a rare use case so I am not
>>>> >>>>>>>>>>> >> >> >>>>>> feeling strongly for or against it. I don't
feel so concerned by the
>>>> >>>>>>>>>>> >> >> >>>>>> examples as IMO they are just examples and
its OK if they don't cover all
>>>> >>>>>>>>>>> >> >> >>>>>> the API (after all it is not the spec).
>>>> >>>>>>>>>>> >> >> >>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>> About supporting deser missing properties I
100% agree with the
>>>> >>>>>>>>>>> >> >> >>>>>> remark but think it should be expressed as a
config option that would make
>>>> >>>>>>>>>>> >> >> >>>>>> things clear that impl. have to support this
feature (and don't really care
>>>> >>>>>>>>>>> >> >> >>>>>> about the example).
>>>> >>>>>>>>>>> >> >> >>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>> I wonder if providing those examples doesn't
make things more
>>>> >>>>>>>>>>> >> >> >>>>>> confusing about what is the contract that
impls should respect.
>>>> >>>>>>>>>>> >> >> >>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>> Eugen
>>>> >>>>>>>>>>> >> >> >>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>> It would be helpful to hear some opinions
from others on this
>>>> >>>>>>>>>>> >> >> >>>>>>> topic.
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>> 3) Expected result in bounded example
doesn't look right:
>>>> >>>>>>>>>>> >> >> >>>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>>>
assertEquals("{\"boundedSet\":[3],\"superList\":[{\"radius\":2.5}]}",
>>>> >>>>>>>>>>> >> >> >>>>>>>>> jsonb.toJson(boundedGenericClass));
>>>> >>>>>>>>>>> >> >> >>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>> I believe it should be:
>>>> >>>>>>>>>>> >> >> >>>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>>>
{"boundedSet":[3],"superList":[{"area":0.0,"radius":2.5}]}
>>>> >>>>>>>>>>> >> >> >>>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>> Will fix asap.
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>> Have a great Easter!
>>>> >>>>>>>>>>> >> >> >>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>> Thank you,
>>>> >>>>>>>>>>> >> >> >>>>>>>> Oleg
>>>> >>>>>>>>>>> >> >> >>>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>>
>>>> >>>>>>>>>>> >> >> >>>>>
>>>> >>>>>>>>>>> >> >> >>>>
>>>> >>>>>>>>>>> >> >> >>>
>>>> >>>>>>>>>>> >> >> >
>>>> >>>>>>>>>>> >> >
>>>> >>>>>>>>>>> >> >
>>>> >>>>>>>>>>> >
>>>> >>>>>>>>>>> >
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> --
>>>> >>>>>>>>>>> Hendrik Saly (salyh, hendrikdev22)
>>>> >>>>>>>>>>> @hendrikdev22
>>>> >>>>>>>>>>> PGP: 0x22D7F6EC
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> --
>>>> >>>>>>>>>>> Hendrik Saly (salyh, hendrikdev22)
>>>> >>>>>>>>>>> @hendrikdev22
>>>> >>>>>>>>>>> PGP: 0x22D7F6EC
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>
>>>> >>>>>>>>
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>
>>>> >>
>>>> >
>>>
>>>
>>
>