Java Class to LH VariableType Conversion Problems

[Snarr]

Background

In our Java SDK, we often perform an operation where we try to map a Java Class to an LH VariableType:

@LHTaskMethod("greet")
public String greeting(String name) {
    log.debug("Executing task greet");
    return "hello there, " + name;
}

Take the above example. We define a TaskDef 'greet' using the method 'greeting'. We map a Java class to an LH VariableType three times:

1. We define that the TaskDef with have an input variable String name in the method definition. Behind the scenes, sdk-java code checks the class of that input variable and sorts it into one of the following VariableType categories: STR, INT, DOUBLE, BOOL, BYTES, JSON_OBJ, JSON_ARR.
2. We define that the TaskDef will output a String in the method definition. Behind the scenes, sdk-java code checks the class of that return type and sorts it into one of the aforementioned VariableType categories.
3. We return an instance of an object, in this case a String "hello there, " + name. Behind the scenes, sdk-java code checks the class of that object and sorts it into one of the aforementioned VariableType categories.

This works well when the Java Class has a matching LH VariableType, like how in the above examples String would always map to VariableType.STR.

However, we run into some problems when there isn't a perfect mapping between the Java Class and the LH VariableType...

Problem

@LHTaskMethod("get-user-uuid")
public UUID getUserUUID(String username) {
    UUID uuid = lookupUUID(username);
    return uuid;
}

Take the above example, where we defined a TaskDef that takes in a String username and returns a Java UUID object. The server handles the input just fine, it maps String to STR. Things fall apart quickly when we take a look at the declared Return Type and the Returned Object at runtime.

Mapping the Return Type

The return type gets mapped to a VariableType by the following sdk-java method 'javaClassToLHVarType':

public static VariableType javaClassToLHVarType(Class<?> cls) {
    if (Integer.class.isAssignableFrom(cls)
                || Long.class.isAssignableFrom(cls)
                || int.class.isAssignableFrom(cls)
                || long.class.isAssignableFrom(cls)) return VariableType.INT;

    if (Double.class.isAssignableFrom(cls)
                || Float.class.isAssignableFrom(cls)
                || double.class.isAssignableFrom(cls)
                || float.class.isAssignableFrom(cls)) return VariableType.DOUBLE;

    if (String.class.isAssignableFrom(cls)) return VariableType.STR;

    if ((Boolean.class.isAssignableFrom(cls) || boolean.class.isAssignableFrom(cls))) return VariableType.BOOL;

    if (byte[].class.isAssignableFrom(cls)) return VariableType.BYTES;

    if (List.class.isAssignableFrom(cls)) return VariableType.JSON_ARR;

    return VariableType.JSON_OBJ;
}

The java.util.UUID class implements java.io.Serializable and Comparable<UUID>. So it doesn't match our conditions for an Integer, a Double, a String, a Boolean, a byte[], nor a List. Since it didn't pass any of the aforementioned cases, our UUID gets mapped into the JSON_OBJ VariableType.

Mapping the Returned Object at Runtime

When we run the Task Method and it returns a UUID object, we cast the object to a compatible VariableType. The casting is performed by the objToVarVal method:

public static VariableValue objToVarVal(Object o) throws LHSerdeError {
        if (o instanceof VariableValue) return (VariableValue) o;

        VariableValue.Builder out = VariableValue.newBuilder();
        if (o == null) {
            // nothing to do
        } else if (Long.class.isAssignableFrom(o.getClass())) {
            out.setInt((Long) o);
        } else if (Integer.class.isAssignableFrom(o.getClass())) {
            out.setInt((Integer) o);
        } else if (Double.class.isAssignableFrom(o.getClass())) {
            out.setDouble((Double) o);
        } else if (Float.class.isAssignableFrom(o.getClass())) {
            out.setDouble((Float) o);
        } else if (o instanceof String) {
            out.setStr((String) o);
        } else if (o instanceof Boolean) {
            out.setBool((Boolean) o);
        } else if (o instanceof byte[]) {
            out.setBytes(ByteString.copyFrom((byte[]) o));
        } else {
            // At this point, all we can do is try to make it a JSON type.
            JsonResult jsonResult = LHLibUtil.serializeToJson(o);

            switch (jsonResult.getType()) {
                case ARRAY:
                    out.setJsonArr(jsonResult.getJsonStr());
                    break;
                case OBJECT:
                    out.setJsonObj(jsonResult.getJsonStr());
                    break;
                case PRIMITIVE:
                    // Trims the quotes off the string
                    out.setStr(jsonResult
                            .getJsonStr()
                            .substring(1, jsonResult.getJsonStr().length() - 1));
                    break;
                case NULL:
                    break;
                default:
                    throw new LHSerdeError("Failed serializing object to Json: " + o.toString());
            }
        }

        return out.build();
    }

Similarly to the return type conditions, our UUID object is not an instance of the following Java classes: Long, Integer, Double, String, Boolean, and byte[]. However, once we make it past those conditions, we still need to cast the object into a compatible format or we can't send it to the server at all. So we try to cast it using GSON (previously Jackson, but the same outcome applies). GSON does some magic behind the scenes and casts the UUID to a String, since the UUID object doesn't neatly serialize into any other JSON types.

Different Results

Our Return Type UUID mapped to the VariableType JSON_OBJ
Our Returned Object, an instance of UUID, mapped to the VariableType STR.

JSON_OBJ != STR

The crux of the problem is that our two methods for mapping from the Java domain to the LittleHorse domain are different. The first method, javaClassToLHVarType, maps our UUID class to a JSON_OBJ, since it doesn't match any of the other conditions. Our second method, objToVarVal, casts our UUID object to a STR, since the UUID object doesn't map into a JSON_OBJ nicely.

What is the solution?

My knee-jerk reaction to this is to unite the two mapping implementations.

It is incredibly difficult to cast UUID objects to a JSON_OBJ neatly. It is hard to articulate all the unique cases that make this difficult, which is why our current solution casts them to STRs. So changing the mapping implementation for objToVarVal would be difficult.

If we were to change the Return Type mapping solution to match objToVarVal, we run into a similar set of problems. How do we map a UUID to a STR in a way that respects other unique cases such as Currency, Date, and Calendar. We also need to make sure that users can still define POJOs (Plain Old Java Objects) that map into JSON_OBJ still.

I am not sure what the solution here is. Maybe we should reduce the amount of magic mappings going on behind the scenes, and allow users to declare their own Serializers and Deserializers for non-standard class types.