Getters/setters instead of fields

[Jaka Jančar]

Hi!

I read in the design document that you intend to enhance Gson to
support properties in addition to fields.

Is there any ETA or actual work being done on this, or is it just
something that will happen "someday"? :)

Thanks,
Jaka

[inder]

At the moment, we have no plans to do so.

We haven't seen a compelling use-case yet. The only interesting one is
when you are using an Interface as the field type while deserializing.
But haven't seen loud enough complaints yet. :)

Inder

[Jaka Jančar]

The reasons are the same as for using getters/setters instead of
fields elsewhere (executing some code when values are to be changed).

Since I think the design of Gson is brilliant and I know you're one of
the developers, I'll assume that you're right and know something I
don't :)

My situation is that I have a bunch of JPA-persisted entities which
have lots of very basic logic (validation, filtering (trimming of
whitespace, capitalization fixes...), etc.). I would like to expose
and consume these via Gson.

Do you have a separate set of DTOs just for Gson?

What am I missing here?

Jaka

2009/4/16 inder <inde...@gmail.com>:

[inder]

Thanks for the compliments on the Gson design and glad to know that
you liked it. :)

When we started Gson, there were bunch of requests for supporting
properties and we thought that it would be a good addition. However,
as the project progressed we didn't really see a stronger need
emerging for this. Overall, Gson is heavily field-centric and allowing
properties will probably just complicate the design and create
unintended side-effects. For example, Gson constructs an object
instance using the default constructor. However, it writes fields in
an unspecified order. Would your validation logic expect a certain
order of field initialization?

You raise a good point about using the validation logic for the
fields. I think that is a reasonable use-case to support.
I would like to know more about how you plan to reuse the JPA
entities. Are you directly exposing these in a Web-service? Is this a
firmed up design or something that is being done for expediency and
will be changed later?

Is there another way we can support this? For example, what if we
supported a method annotation @onPostCreate that was called after Gson
finished initializing an object? Will you be easily able to move your
validation logic there? I think JPA has something similar.

Thanks
Inder

On Apr 16, 10:20 am, Jaka Jančar <j...@kubje.org> wrote:
> The reasons are the same as for using getters/setters instead of
> fields elsewhere (executing some code when values are to be changed).
>
> Since I think the design of Gson is brilliant and I know you're one of
> the developers, I'll assume that you're right and know something I
> don't :)
>
> My situation is that I have a bunch of JPA-persisted entities which
> have lots of very basic logic (validation, filtering (trimming of
> whitespace, capitalization fixes...), etc.). I would like to expose
> and consume these via Gson.
>
> Do you have a separate set of DTOs just for Gson?
>
> What am I missing here?
>
> Jaka
>

> 2009/4/16 inder <inder...@gmail.com>:

[Jaka Jančar]

Problems with setter order (or using @onPostCreate) implies that your
object can be in an invalid state for a while, which I think isn't
good. (With @onPostCreate your classes don't even "work properly" on
their own, but need support of Gson, JPA or whatever.)

For properties that are so interrelated that they have this problem
(e.g. year/month/date), it would make sense put them into a separate
class (Date).

And classes already have a mechanism to solve this: constructors.

I was thinking about annotating the constructors with property names
(because the parameter names aren't retained at runtime) and using a
custom InstanceCreator. For example a Person that always needs a valid
firstName and a lastName would have the constructor:

@ConstructorProperties({"firstName", "lastName"})
public Person(String firstName, String lastName);

Then when a Person needed to be created, properties firstName and
lastName would be passed into the constructor.

However after looking into this a bit more, I don't think it's
currently possible, since InstanceCreator#createInstance(Type type)
doesn't have access to the properties "in advance". Would this be easy
to fix, or does it break the whole philosophy?

As for the reuse of JPA entities: I think if you could build detached
entities using Gson like this, you could use EntityManager#merge() to
update persistent ones directly.

But this is my fallback plan. Currently, I'm working on something
(imo) a bit cooler. If you're interested, see:

http://stackoverflow.com/questions/731989/partial-bean-serialization-and-deserializationmerging

Jaka

[inder]

> I was thinking about annotating the constructors with property names
> (because the parameter names aren't retained at runtime) and using a
> custom InstanceCreator. For example a Person that always needs a valid
> firstName and a lastName would have the constructor:
>
> @ConstructorProperties({"firstName", "lastName"})
> public Person(String firstName, String lastName);
>
> Then when a Person needed to be created, properties firstName and
> lastName would be passed into the constructor.

This leads to a slippery slope of incorporating all of Guice
functionality into Gson. For example, what if the Constructor
parameters are rich Java types themselves? The code is not all that
hard to write (especially since Guice already does it) but probably
has much more unintended consequences than what we have. We dont want
Gson to turn into a mini-Guice.

What you are asking for can actually be done fairly simply by
registering your own custom deserializer that does the needed work
itself and calls Context.deserialize() for the remaining stuff. We
are also planning to provide a Context.serializeInternal() method (see
http://code.google.com/p/google-gson/issues/detail?id=43) that can be
used as to create a Deserializer that in-effect is a post or pre
create invocation.

I understand that for JPA entities, you do not want to write a custom
deserializer for each entity. You probably would prefer just
annotating the classes themselves with extra annotations. However,
that will pollute them with an external represenation and is probably
harder to maintain.

> However after looking into this a bit more, I don't think it's
> currently possible, since InstanceCreator#createInstance(Type type)
> doesn't have access to the properties "in advance". Would this be easy
> to fix, or does it break the whole philosophy?

If Gson is doing all the work then we can do anything we want.
However, if its a user-written instance creator then we have to see
how we can accomplish this while maintaining backwards compatibility.

I am not sure why you would not just write a deserializer instead of
an InstanceCreator in this case. Deserializers have full access to the
properties. InstanceCreators do not (that was an oversight while
designing our API, we should have provided Json tree as a parameter).
But InstanceCreators are not really necessary for most cases. They are
just an optimization when all you want to do is to provide an ability
to create a default instance.

> As for the reuse of JPA entities: I think if you could build detached
> entities using Gson like this, you could use EntityManager#merge() to
> update persistent ones directly.
>
> But this is my fallback plan. Currently, I'm working on something
> (imo) a bit cooler. If you're interested, see:
>

> http://stackoverflow.com/questions/731989/partial-bean-serialization-...

Cool. IMHO it is useful to introduce additional facades for Web layer
and not expose the database entities directly. If you decide to do so,
Gson will be much easier to use.

Thanks
Inder

[Julio Viera]

Hi,

Check https://github.com/julman99/gson-fire