narayana1208 / google-gson

Automatically exported from code.google.com/p/google-gson
0 stars 0 forks source link

Enum constant does not exist #165

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
This isn't a bug per say, more of a starting point for a conversation. Our
organization uses GSON to pass data between two internal applications, both
running in Java. Both applications depend on a particular in-house library,
but the receiving end isn't guaranteed to have the same version as the
sending end. This has caused some problems with our use of enums, when the
sender has knowledge of enum constants that the receiver does not know
about. It might be nice to have a way to optionally silently ignore these
mis-matches on the receiver. We have a solution that works for us, and are
somewhat curious if this is an issue for anyone else out there.

What steps will reproduce the problem?
1. Serialize an object that has an enum property to JSON
2. Deserialize the JSON in another application that does not have that enum
constant available

What is the expected output? What do you see instead?

That is the big question. In our particular instance, we would just want
that enum to be ignored. If the class that has the enum looked like

public class Something {
MyEnum a;
}

And MyEnum had "A" and "B", if the JSON said it should be "C", I would want
the property "a" to be null.

In another instance in our application, we have a class:

public class SomethingElse {
Set<MyEnum> flags;
}

If a constant of "C" were coming through in JSON, I would expect this set
to be empty, if the application containing it only knew about A and B.

What version of the product are you using? On what operating system?
Any

Please provide any additional information below.

We have overcome the first example by making our own type adapter, based on
the built-in one, that looks like:

public class EnumSafeChangeTypeAdapter<T extends Enum<T>> implements
JsonSerializer<T>, JsonDeserializer<T> {
    public JsonElement serialize(T src, Type typeOfSrc,
JsonSerializationContext context) {
        return new JsonPrimitive(src.name());
    }

    // The NULL here needs to be coupled with an instancecreator that returns
    // null as well. See VzLite for an example of this
    @SuppressWarnings("cast")
    public T deserialize(JsonElement json, Type classOfT,
JsonDeserializationContext context) throws JsonParseException {
        try {
            return (T) Enum.valueOf((Class<T>) classOfT, json.getAsString());
        }
        catch (Exception e) {
            return null;
        }
    }

    @Override
    public String toString() {
        return EnumSafeChangeTypeAdapter.class.getSimpleName();
    }
}

Also, we have to register an instance creator to handle the null, otherwise
we get other exceptions:

GsonBuilder builder = new GsonBuilder();
builder.registerTypeAdapter(Enum.class, new InstanceCreator<Enum<?>>() {
public Enum<?> createInstance(Type type) {
return null;
}
});

Original issue reported on code.google.com by danw...@gmail.com on 12 Oct 2009 at 8:29

GoogleCodeExporter commented 9 years ago
Glad to know that you could register a custom type adapter to address your 
use-case. 
We wouldn't like to change the design of Gson to silently ignore invalid Enum 
values 
as it may mask real bugs. Some organization prefer the fail-fast approach to 
detect 
bugs.

Original comment by inder123 on 15 Oct 2009 at 4:10

GoogleCodeExporter commented 9 years ago
Sorry for jumping in a bit late here.  What version of Gson are you running 
that requires you to register both a custom deserializer and an instance 
creator.  I know we had that bug a while back, but I thought it was fixed in 
version 1.3 and later.

Is it possible to use the Gson versioning to protect you from the 
sender/receiver incompatibilities? The common approach for API versioning is 
that the client will request the API version it would like to use with the 
server. The server is then able to process and respond to the client without 
breaking backward compatibility. As new features get added to API calls (or new 
API calls emerge) then the server should support a new version. 

Original comment by joel.leitch@gmail.com on 21 Aug 2010 at 8:31

GoogleCodeExporter commented 9 years ago

Original comment by inder123 on 3 Nov 2010 at 1:45

GoogleCodeExporter commented 9 years ago
I do not consider this a Gson issue, but rather a versioning issue between the 
client and server.

Original comment by joel.leitch@gmail.com on 22 Mar 2011 at 10:15