Support for union types

[joelittlejohn]

Original author: joelittl...@gmail.com (February 23, 2011 10:31:27)

The idea of union types is potentially quite incompatible with Java so we may end up with a fairly naive implementation here that offers support for union types only in the most basic sense. I'd like to think that jsonschema2pojo could at least avoid messy failure when a union type is encountered.

I have a few ideas for how this could be implemented:

1. On detecting a union type, just take the first type and proceed as normal. This is not fantastically useful (union types would still be avoided when writing schemas for jsonschema2pojo) but at least code generation could continue.
2. On detecting a union type, create some marker interface which all types in the union will implement. This allows relationships between the POJOs to remain rigidly enforced. This can't work for primitive types though, e.g. {"type" : ["integer","string"]}.
3. On detecting a union type, proceed to generate the two or more types specified (if they are complex), but mark any usages of that union type as java.lang.Object. Relationships between the generated POJOs become a bit more difficult to understand, and it becomes quite easy to compose Java objects in a way that will produce invalid JSON.

Both option 2 and 3 would likely need to take advantage of Jackson's polymorphic deserialization features:
http://wiki.fasterxml.com/JacksonPolymorphicDeserialization
http://jira.codehaus.org/browse/JACKSON-91

At the moment, I'm thinking Option 3 is the most sensible/useful.

Original issue: http://code.google.com/p/jsonschema2pojo/issues/detail?id=17

[joelittlejohn]

From PMarchw...@lbl.gov on May 07, 2012 22:19:27
The only time I have used union types is to allow null for a field. Note that the schema calls out this use case specifically in section 5.1 :
" null Value MUST be null. Note this is mainly for purpose of
being able use union types to define nullability. If this type
is not included in a union, null values are not allowed (the
primitives listed above do not allow nulls on their own)."

A lot of the types for my fields look like: {"type": ["string","null"]}
I only speak from my experience so I don't know how commonly used this is but it should be simple to add a special case for it. It would work seamlessly as long as boxed types are being used.

[joelittlejohn]

From joelittl...@gmail.com on May 08, 2012 21:55:44
This issue has been around for a while and I'm now leaning away from the 3rd option described above. It would be nice to have a simple implementation for now that doesn't impose any additional requirements on the json (like extra 'type' properties).

I've fixed this as per Option 1: if an array is encountered (a union type) just use the first type in the array. Maybe a more sophisticated handling of union types could be applied to a later version, but in general if you want to do data-binding to a statically typed language like Java it's best to avoid such constructs.

This should satisfy your use-case Patrick, just make sure the "null" type comes last.