83

Why does GSON use ONLY fields(private,public,protected)? Is there a way to tell GSON to use only getters and setters?

Zemzela
  • 3,060
  • 6
  • 23
  • 32

4 Answers4

100

Generally speaking when you serialize/deserialize an object, you are doing so to end up with an exact copy of the state of the object; As such, you generally want to circumvent the encapsulation normally desired in an OO design. If you do not circumvent the encapsulation, it may not be possible to end up with an object that has the exact same state after deserialization as it had prior to serialization. Additionally, consider the case where you do not want to provide a setter for a particular property. How should serialization/deserialization act if you are working through the getters and setters?

Chris Shaffer
  • 32,199
  • 5
  • 49
  • 61
  • 30
    How about "calculated fields" we would like to provide to the external world ? In your way of thinking, I should create a field and update this field everytime I update one of my POJO fields ? Urgh... – Frédéric Camblor Oct 16 '12 at 17:06
  • 2
    @Frédéric - I'm really just pointing out difficulties introduced by using property getters and setters for serialization; Calculated properties would introduce their own problems as well. For example, if you give someone a serialized object, then they update the calculated property's value and pass it back to you, how should the application handle deserialization? Pretend the property wasn't updated or throw an exception? Also, if they update the properties on which the calculated property was based, the object state is actually invalid, and reading that property's value is flat wrong. – Chris Shaffer Oct 16 '12 at 18:53
  • 1
    I agree with @Frédéric; there are some edge cases that merit using properties vice fields. I just ran into one where I have a byte array on an object that I would like to exclude and instead return a String. Now I'm left with adapting the object via DTO. – Richard Clayton Oct 24 '12 at 00:43
  • Calculated/derived fields should be labelled `transient` so they are not serialized, and recalculated on request. – BoffinBrain Feb 06 '13 at 12:27
  • Generally when I serialise an object to JSON, I'm doing it to tell the other party something. Generally when I deserialise an object from JSON, I'm doing it because someone sent it to me in JSON. All the model classes in our system are written as only an interface and then using reflection proxies for implementation. Trying to serialise the fields in this situation is just silly - serialising the properties would have made such a reflection proxy indistinguishable from a manually-coded bean (which is a good thing.) – Hakanai Apr 05 '13 at 04:34
  • 16
    This is fine if the use case is Java to Java serialisation, but a quite common use case is to expose Java object as a result of a REST api call, in that case on the Java side we don't need two way perfect serialisation, much more often we want to hide fields and serialise (and deserialise if/when needed) specific, often run time computed, properties. – Simone Gianni Oct 28 '13 at 01:42
  • Having the ability to tell a serializer to use the getters and setters for a given class, would allow the Hibernate validation to be done on a setter parameter. – Stephane Nov 20 '15 at 14:57
  • @Frédéric i just had to deal with a transient calculated field today. I just calculated it in the getter if `null`. – BlueWizard Dec 11 '16 at 16:18
  • If you want to use your Getter/Setter so bad you could just provide a custom serializer. I do it all the time and it is very straightforward and simple (Tutorial https://sites.google.com/site/gson/gson-user-guide#TOC-Custom-Serialization-and-Deserialization). Often I have some fromJson-Method inside the Object itself – BlueWizard Dec 11 '16 at 16:19
26

Is there a way to tell GSON to use only getters and setters?

Not yet.

From the design doc:

[T]here are good arguments to support properties as well. We intend to enhance Gson in a latter version to support properties as an alternate mapping for indicating Json fields. For now, Gson is fields-based.

snafu109
  • 582
  • 4
  • 13
Programmer Bruce
  • 64,977
  • 7
  • 99
  • 97
  • Concerning Gson support for getters and setters, the latest update on this from the mailing list is that "[t]he prospects of such a feature making into Gson are fairly low..." https://groups.google.com/forum/#!topic/google-gson/4G6Lv9PghUY – Programmer Bruce Jul 02 '11 at 09:26
  • I don't think shouldn't use getters and setters, Chris Shaffer explains this pretty good in this answer. – Sentry Oct 09 '12 at 14:58
  • 4
    Write a custom serializer/deserializer, that way you can use whatever method you want to write the values back into your class. – Dave Birch Dec 15 '14 at 13:25
  • 2
    This answer is very old, stackoverflow does need some "Garbage Collector" for such answers. – Azim Aug 10 '16 at 11:21
  • 1
    @jb nope. The answer is still valid. – 9ilsdx 9rvj 0lo Apr 10 '17 at 14:27
  • I think it's safe to assume they won't add this feature at this point. – JaviCasa Jun 08 '17 at 03:46
6

It is possible to to patch Gson to use getters.

approxiblue
  • 6,982
  • 16
  • 51
  • 59
Jimmy
  • 61
  • 1
  • 1
    I want to be able to designate which variables should use the getter and setter – CQM May 15 '14 at 15:15
0

The vague outline of how this works in our app is that we have a lot of TypeAdapter implementations - some for specific value-like objects and some for bean-style objects where we know that JavaBeans logic will work. We then jam all of these onto a GsonBuilder before creating the Gson object.

Unfortunately, GSON is really crap at handling types like Object[]. We mostly saw this when we were trying to make a JSON object to represent method parameters. The workaround for that was to make custom TypeAdapter instances which reflect the methods. (This does mean that you end up using one Gson instance per method you intend to call...)

Hakanai
  • 12,010
  • 10
  • 62
  • 132
  • How would you sensfully handle deserializing anything to Object? How would you like to guess what that is in order to deserialize it? – 9ilsdx 9rvj 0lo Apr 10 '17 at 14:24
  • For Object, or for polymorphic stuff in general, they could perhaps have an attribute record which adapter originally serialised it. But from memory, I think even obvious stuff like {"a",2,"b"} didn't deserialise to Object[]. – Hakanai Apr 11 '17 at 21:13