Issue 231 in google-gson: First class support for polymorphism (subclasses!)
googl...@googlecode.com
Owner: limpbizkit
Labels: Type-Enhancement Priority-Medium
New issue 231 by limpbizkit: First class support for polymorphism
(subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
GSON always operates on the static type of an object. It has no mechanism
to operate on the object's runtime type.
It would be handy if GsonBuilder permitted a way to specify the known
subclasses of a type. Then at serialization/deserialization these fields
could be included:
public void testPolymorphism() {
Rectangle r = new Rectangle();
r.width = 5;
r.height = 7;
Circle c = new Circle();
c.radius = 3;
List<Shape> shapes = new ArrayList<Shape>();
shapes.add(r);
shapes.add(c);
Gson gson = new GsonBuilder()
.create();
String json = gson.toJson(shapes, new TypeToken<List<Shape>>()
{}.getType());
assertEquals("[{\"width\":5,\"height\":7},{\"radius\":3}]", json);
}
static class Shape {}
static class Rectangle extends Shape {
int width;
int height;
}
static class Circle extends Shape {
int radius;
}
It would be extra awesome if it could use the set of fields in a stream to
infer the type to instantiate. In the example above, it could use that
the 'radius' field as evidence that the runtime type should be a Circle. Or
perhaps this could be user-configured too, such as this:
new GsonBuilder()
.runtimeType(Shape.class, Circle.class, "radius")
.runtimeType(Shape.class, Rectangle.class, "width", "height")
.create();
googl...@googlecode.com
Comment #1 on issue 231 by limpbizkit: First class support for polymorphism
(subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Issue 170 has been merged into this issue.
googl...@googlecode.com
Comment #2 on issue 231 by adri...@quatinus.myzen.co.uk: First class
http://code.google.com/p/google-gson/issues/detail?id=231
It would be more robust to support a custom JSON schema that serializes
runtime type information explicitly (akin to xsi:type in XML) rather than
trying to guess the type by field name matching (if two unrelated classes
had the same fields the guess might be wrong). For example, you could have
Gson.setRuntimeTypeProperty(String) and say
gson.setRuntimeTypeProperty("$type");
Thanks,
Adrian Price
Senior Architect
TIBCO Software Inc.
googl...@googlecode.com
Comment #3 on issue 231 by limpbizkit: First class support for polymorphism
(subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Issue 237 has been merged into this issue.
googl...@googlecode.com
Comment #4 on issue 231 by limpbizkit: First class support for polymorphism
(subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Issue 238 has been merged into this issue.
googl...@googlecode.com
Comment #5 on issue 231 by limpbizkit: First class support for polymorphism
(subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Issue 209 has been merged into this issue.
googl...@googlecode.com
Comment #6 on issue 231 by ray.a.conner: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
I concur with Adrian, except that it would be best if the JSON property
holding the explicit runtime type were not configurable at all, just for
simplicity's sake. However, you can only do that if the prop name is
something that can't be a Java identifier name, to avoid clashing. I'm
guessing the serializer would have to be configured for whether or not to
output that information, maybe only on particular fields or classes. But
the deserializer would not have to configured; it would simply use the
runtime type if present, and behave the old way if not.
At any rate, I would also like to see this done. Not being able to handle
polymorphism is pretty much a non-starter for a rich data model. Is there a
workaround, even if painful? If so, could you post something showing how it
could be done?
- Ray A. Conner
googl...@googlecode.com
Comment #7 on issue 231 by limpbizkit: First class support for polymorphism
(subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Issue 129 has been merged into this issue.
googl...@googlecode.com
Comment #8 on issue 231 by ray.a.conner: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Let me give another counter-example (pseudo-code), which I would really
like to turn into json:
class AllPredicate< T > implements Predicate< T > {
List< Predicate< T > > operands;
}
I always avoid specifying a concrete type if an appropriate interface
exists.
googl...@googlecode.com
Comment #9 on issue 231 by adri...@quatinus.myzen.co.uk: First class
http://code.google.com/p/google-gson/issues/detail?id=231
I disagree with the suggestion in Comment#6 that the type property name
should be hard-coded. We're talking about a *custom* JSON schema so IMO
such a property needs to be configurable (just as the mechanism for
resolving and deresolving the type name needs to be extensible, to allow
use of other metamodels besides Java, e.g., XSD, UML, EMF). I suppose you
could store the custom type property name in some hard-coded property on
the root JSON object (e.g., gson:type_property) and of course there should
be a sensible default type property name (e.g., gson:type) and a usable
default metamodel (e.g., JavaTypeSystem).
By the way there are other custom JSON schema extensions that are also
required to support *formal modelling* semantics properly, such as the
notion of element identity and the distinction between UML-style
composition aggregation associations versus non-aggregating associations.
As things currently stand a Java object graph in which multiple elements
refer to a single object, the referenced object will be replicated in the
serialized JSON and will deserialize into multiple identical objects rather
than a single instance as in the original. Not at all what is required of a
non-aggregating association!
Adrian Price
googl...@googlecode.com
Comment #10 on issue 231 by ray.a.conner: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
I'll admit it's a bad idea to hard-code that. My main concern was keeping
the number of things that the programmer has to do to a minimum, convention
over configuration. I've found that the more you make a programmer do,
especially if it has to be consistent in two or more places, the more
likely it will be done incorrectly.
googl...@googlecode.com
Comment #11 on issue 231 by joel.leitch: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
You should try the Hierarchical Type Adapter feature to see if this helps
simplify your problem. Basically, it appears that you will need to push the
sub-classing logic into it.
The official announcement for the release is here:
http://groups.google.com/group/google-gson/browse_thread/thread/6272c9be58676e47
googl...@googlecode.com
Status: Fixed
Comment #12 on issue 231 by joel.leitch: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Fixed in r828.
googl...@googlecode.com
Comment #13 on issue 231 by limpbiz...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Issue 321 has been merged into this issue.
googl...@googlecode.com
Status: Started
Comment #14 on issue 231 by limpbiz...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
This wasn't fixed by r828. But I'm going to implement this. Here's my
proposed API:
RuntimeTypeAdapter<BillingInstrument> grta
= new RuntimeTypeAdapter(BillingInstrument.class, "type");
grta.registerSubtype(CreditCard.class, "CC");
grta.registerSubtype(Paypal.class, "PayPal");
grta.registerSubtype(BankTransfer.class); // defaults to the simple
name, "BankTransfer"
This would synthesize a type field in the emitted JSON as a hint during
deserialization:
/*
* "billingInstruments": [
* {
* "type": "CC",
* "cvv": 234
* },
* {
* "type": "PayPal",
* "email", "je...@swank.ca"
* }
* ]
*/
googl...@googlecode.com
Comment #15 on issue 231 by adrianp....@virginmedia.com: First class
http://code.google.com/p/google-gson/issues/detail?id=231
Again, I urgently entreat you *not* to hard code the custom schema in the
way suggested by comment #14. For a start, the namespace for 'meta-type'
attributes like this *must* be something that won't collide with
application metamodels. If you hard code it as 'type' then you won't be
able to serialize any object that has a legitimate 'type' attribute. They
made the same mistake in SDO and it ruined an otherwise lovely
specification. At the very least, provide a mechanism for customizing such
meta-attribute names.
googl...@googlecode.com
Comment #16 on issue 231 by limpbiz...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
@adrianp agreed. Thats howhy 'new RuntimeTypeAdapter' takes two arguments!
googl...@googlecode.com
Comment #17 on issue 231 by adrianp....@virginmedia.com: First class
http://code.google.com/p/google-gson/issues/detail?id=231
Ahh... I get it now. Sorry, I should have studied the code snippet more
carefully. Looks good! :-)
googl...@googlecode.com
Comment #18 on issue 231 by david.nouls: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
@comment 13: is there a build available ? I really need polymorphism when
serialising. The 1.7.1 release does not seem to support it correctly.
googl...@googlecode.com
Comment #19 on issue 231 by jessewil...@google.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
It isn't done yet! But you can take a look at RuntimeTypeAdapter.java in
svn if you'd like something urgently.
googl...@googlecode.com
Comment #20 on issue 231 by david.nouls: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
I tried with a build of trunk and it fixes my serialisation issues. So
hopefully there will be a new release coming soon. There were 4 unittest
failing in the trunk.
googl...@googlecode.com
Comment #21 on issue 231 by jshlcl...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Yes, comment 13 would be very useful!
googl...@googlecode.com
Comment #22 on issue 231 by jshlcl...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Yes, comment 14 would be very useful!
googl...@googlecode.com
Comment #23 on issue 231 by jshlcl...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Yes, comment 14 would be very useful! Another way that you can get around
this solution as a coder, if you are using polymorphism in a List: for
your abstract class, keep a counter variable in it, and save
separate "subclasses" in the counter for order. When serializing, create
separate saved files as Json strings to keep track of what subclass you are
using. Then when you deserialize the data to information and load it into
each of your classes, load the data to each of your subclasses in the order
your abstract class detailed the order as.
googl...@googlecode.com
Comment #24 on issue 231 by ahhug...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Would be great to see something like Comment #14 appear :)
What would happen if "type" : "..." was not in the json example? It should
still be possible determine the correct subtype based on the contents of
the json. Could the API outsource this test? The only other alternative is
that multiple RuntimeTypeAdapter's are created... and that seems very
problematic too...
Don't read too deeply into this code, I'm shooting from the hip...
RuntimeTypeAdapter<BillingInstrument> grta = new
RuntimeTypeAdapter(BillingInstrument.class);
grta.registerSubtype(CreditCard.class, new IsSubtype(){
@override
public boolean isSubType(JsonElement jsonElement){
//if the json has a "cvv" then yes, its a CreditCard. But this
could be something far more complicated...
return jsonElement.getAsJsonObject().get("cvv") != null;
}
});
Other notes, would reflection/introspection be of use to produce re-usable
IsSubType's? If so, then the IsSubtype should probably have access to the
class also (and not just the jsonElement alone).
googl...@googlecode.com
Comment #25 on issue 231 by jessewil...@google.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
@ahhughes: detecting based on the fields is possible but definitely not
very reliable. If you'd like to do that, you should write your own type
adapter!
googl...@googlecode.com
Comment #26 on issue 231 by oxygene.core: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Is it possible to divide serialization to jsonTree from deserialization
from jsonTree? Implementation of serialization looking to be very
straightforward (without using marker field), and in some cases it is
enough to just serialize bean and not deserialize.
In my case (website) I'm using strictly typed deserialization to bean (ajax
posts) and dynamic typed serialization (event mechanism - events are sent
back to client and processed via JS).
googl...@googlecode.com
Comment #27 on issue 231 by klov...@virtuoz.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
I notice that the "RuntimeTypeAdapterFactory" class is at the moment
in "extras", will it be part of the 2.0 release anyway?
googl...@googlecode.com
Comment #28 on issue 231 by klov...@virtuoz.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
I notice that the "RuntimeTypeAdapterFactory" class is at the moment
in "extras", will it be part of the next release anyway?
googl...@googlecode.com
Comment #29 on issue 231 by limpbiz...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
RuntimeTypeAdapterFactory won't be in GSON 2.0.
googl...@googlecode.com
Comment #30 on issue 231 by tommytcc...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
There is a simple solution for this..override the default
CollectionTypeAdapter to not use the defined parameterized type.
for example:
private class RunTimeTypeCollectionAdapter implements
JsonSerializer<Collection> {
@Override
public JsonElement serialize(Collection src, Type typeOfSrc,
JsonSerializationContext context) {
if (src == null) {
return null;
}
JsonArray array = new JsonArray();
for (Object child : src) {
JsonElement element = context.serialize(child);
array.add(element);
}
return array;
}
}
in your gson builder, use this:
new GsonBuilder().registerTypeHierarchyAdapter(Collection.class, new
RunTimeTypeCollectionAdapter())
googl...@googlecode.com
Comment #31 on issue 231 by inder123: First class support for polymorphism
(subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
In the current implementation of RuntimeTypeAdapterFactory, the Shape class
is forbidden to have a field that can be used as type. This is sometimes
desirable when you know the limited number of shapes you are going to use:
enum ShapeType {
RECTANGLE, CIRCLE
}
static class Shape {
private final ShapeType shapeType;
protected Shape(ShapeType shapeType) {
this.shapeType = shapeType;
}
}
Now, if I use:
RuntimeTypeAdapterFactory shapeTypeAdapterFactory =
RuntimeTypeAdapterFactory.of(Shape.class, "shapeType");
shapeTypeAdapterFactory.registerSubType(Rectangle.class);
shapeTypeAdapterFactory.registerSubType(Circle.class);
new
GsonBuilder().registerTypeAdapaterFactory(shapeTypeAdapterFactory).create();
This will result in a runtime error:
com.google.gson.JsonParseException: cannot serialize Rectangle because it
already defines a field named shapeType
at
com.trymph.definition.gson.RuntimeTypeAdapterFactory$1.write(RuntimeTypeAdapterFactory.java:228)
at
com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:68)
at
com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.write(MapTypeAdapterFactory.java:240)
at
com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.write(MapTypeAdapterFactory.java:1)
at
com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:68)
at
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:89)
at
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:195)
at com.google.gson.Gson.toJson(Gson.java:582)
at com.google.gson.Gson.toJson(Gson.java:561)
at com.google.gson.Gson.toJson(Gson.java:516)
Suggestions on how to revise RuntimeTypeAdapterFactory which will take care
of this situation better?
googl...@googlecode.com
Comment #32 on issue 231 by l...@ghue.net: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
What about pre-pending a character that is illegal in a java field so there
won't be collisions?
googl...@googlecode.com
Comment #33 on issue 231 by chinju18...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Hi,
I need to know how we can deserialize an object which contains a list of
type abstract class as an attribute using gson
code eg:
class A{
List<B> list;
}
public abstract class B{
}
..
googl...@googlecode.com
Comment #34 on issue 231 by m...@foursquare.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Any movement on this? Comment #14 seems like an option. Not sure if #30
made it in either. I thought gson would have had this down easy due to its
popularity.
googl...@googlecode.com
Comment #35 on issue 231 by limpbizkit: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Implemented by:
http://code.google.com/p/google-gson/source/browse/trunk/extras/src/main/java/com/google/gson/typeadapters/RuntimeTypeAdapterFactory.java
We aren't (yet) including this in the core API so your best bet is to
include the source in your app.
googl...@googlecode.com
Comment #36 on issue 231 by pjpi...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
The current javadoc is incorrect. One should read the following:
RuntimeTypeAdapterFactory<Shape> shapeAdapter =
RuntimeTypeAdapterFactory.of(Shape.class)
.registerSubtype(Rectangle.class)
.registerSubtype(Circle.class)
.registerSubtype(Diamond.class);
Gson gson = new
GsonBuilder().registerTypeAdapterFactory(shapeAdapter).create();
Shape rectangle = new Rectangle(..);
jsonString = gson.toJson(rectangle, Shape.class);
googl...@googlecode.com
Comment #37 on issue 231 by pareshpv...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Dear all,
This RuntimeTypeAdapterFactory is the solution for registering the Type and
subType.
As per our requirement : if custom object comes from server then i will
define only one top level type which is pass as in fromJson() api's second
parameter,
Runtime it will manage all suptypes.
Does it possible to manage this without type and subtype registration ?
Lets take one example.
Class A{
// fields
}
Class B extends A{
// fields
}
Class C extends A{
// fields
}
Class D extends A{
// fields
}
Class Test extends A{
public List<A> contents = new ArrayList<A>(); // it may contain A, B, C
etc.
private boolean isHeader = false;
private String myTestString = "test";
}
Is there any way to write without registering type and subtype?
as here define runtimeTypeAdapter in TypeAdapterRuntimeTypeWrapper,
is there any other solution put logic here or other place?
is in read logic as per "type" can we create runtime adapter as per "type"
coming?
it coming in ReflectiveTypeAdapterFactory in read() of Adapter<T>
googl...@googlecode.com
Comment #38 on issue 231 by rhd...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
If I understand this Issue (231) correctly (which i may not), are we not
talking about the limitation of not being able to deserialize arbitary
collections of objects? If that is the case, a reasonable solution would
seem to be easy enough: just have a config option to (optionally) serialize
an object's java class along with its other fields. The field could be
named something like com_google_gson_java_class and simply be a string with
the class name. Easy to serialize. Easy to deserialize.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
googl...@googlecode.com
Comment #39 on issue 231 by adrianp....@virginmedia.com: First class
Re. #38, we're not talking specifically about collections per se, the
principle applies as much to single-valued as multi-valued properties. It's
more about preserving runtime type information in the JSON so that the
original object class can be re-instantiated by custom type adapters when
deserializing the JSON. As I mentioned in #9, the type scheme needs to be
extensible so that it can be made to work with XSD, UML, EMF, not
specifically the Java type system. For example, I'd like to be able to
serialize dynamic EMF EObjects - these are all instances of
org.eclipse.emf.ecore.impl.DynamicEObjectImpl but their eClass is different
and it is their qualified EClass name (e.g., as package-ns-prefix:type)
that one would wish to serialize as the runtime type name.
googl...@googlecode.com
Comment #40 on issue 231 by DavidTP...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Thanks for the RuntimeTypeAdapterFactory guys, been using it in some
production code and it is working quickly and as expected for handling a
collection of JSON objects which can be one of many types.
googl...@googlecode.com
Comment #41 on issue 231 by kamui.ji...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Hey guys.
A simple case I try to solve with RuntimeTypeAdapterFactory of yours.
JSON field can be either an JSONObject or String.
How would I parse it?
googl...@googlecode.com
Comment #42 on issue 231 by nbpr...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
What's the hold up on this - it seems like there were perfectly good
suggestions made, and implementation created. Can you share the thinking
behind why its not yet in the library?
googl...@googlecode.com
Comment #43 on issue 231 by julio.vi...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Check out https://github.com/julman99/gson-fire, it has this feature and
other ones that personally I think they are missing from Gson.
googl...@googlecode.com
Comment #44 on issue 231 by tamino.h...@gmail.com: First class support for
polymorphism (subclasses!)
http://code.google.com/p/google-gson/issues/detail?id=231
Hi!
I've tried using the RuntimeTypeAdapterFactory, and it works fine, except
for one small caveat: when serializing objects within lists within objects,
the type field is left out. For example, this is what I expect:
{"$type":"Area","locations":[{"$type":"Location", "coordinateX":34.0,"coordinateY":57.0,"wifiMorsels":[...]}
But this is what I get:
{"$type":"Area","locations":[{"coordinateX":34.0,"coordinateY":57.0,"wifiMorsels":[...]}
Note that the Area object is also within an object (meaning that simple
nested objects works) and that wifiMorsels is another list where the
contained objects lack the type field and value.
In my case I'll be using the same code on both sides of the JSON-based
communication, so I require the $type field to work.
Any help is greatly appreciated!
googl...@googlecode.com
Comment #45 on issue 231 by canemacc...@gmail.com: First class support for
polymorphism (subclasses!)
https://code.google.com/p/google-gson/issues/detail?id=231
Hi!
Very cool feature! I've found just a little problem: suppose to have:
public class Person {}
public class Student extends Person {}
And suppose to have a Jersey resource like this:
@Path("/")
public class PersonController {
@GET
@Path("/student1")
@Produces(MediaType.APPLICATION_JSON)
public Student getStudent1() {
return new Student();
}
@GET
@Path("/student2")
@Produces(MediaType.APPLICATION_JSON)
public Person getStudent2() {
return new Student();
}
}
In this example, only the second method will work, because into
RuntimeTypeAdapterFactory this condition return false (first instruction of
create method):
if (type.getRawType() != baseType)
I suggest to change that line with
if (!baseType.isAssignableFrom(type.getRawType()))
In this way, I think RuntimeTypeAdapterFactory is more transparent, because
doesn't require to always use the super type to serialize the object.