JSON from Java to C# and back again

Recently I needed to send JSON between Java and C# over an existing SOAP gateway.

On the C# side I used Jayrock, which required a painless recompile to support strong names on the assemblies.

On the Java side I initially used Jettison with XStream, but Jettison’s output is not “pure JSON”, at least not the same as other JSON I have seen and the JSON that Jayrock produces.

Jettison’s JSON:

• puts a root node of the fully qualified class name
• names string elements “string” and string arrays “string-array”

While it’s probably possible to work around these in Jettison (or Jayrock) I though it would be more straight forward to use a library that produced more pure JSON. XStream can export JSON with its JsonHierachicalDriver, but it can not consume JSON (as of 1.3.1). So I turned to Jackson.

After a little work discovering the mix-in annotation method to work with existing static enumeration classes (see an earlier post) Jackson was working fine.

The only other issue was an version of GLUE 4.1.2 (yes it’s old and I’m pushing to upgrade to CXF or Axis2). This GLUE version has a very inefficient “specials” replacement method that replaces quotes with ". Doing the same function with String.replace stopped the CPU from maximising and made each request orders of magnitude faster.

Dependency Injection to avoid circular dependencies

Dependencies injection saves the day again, this time in helping work around a circular dependency.

Often you have to work with legacy code that can not be changed easily. In my case I had a project called Gateway (containing a JSON Gateway) that depends on a project called Common. I needed an instance of a class in Gateway to be used in the Common package. Common has no visibility of classes in Gateway. It would create a circular dependency if Gateway was changed to depended on Common.

Keep in mind that major restructuring was not an option due to legacy code and time constraints. There are some bigger issues that are causing the problem, but I needed a simple solution for now.

To solve this problem, I made an interface in Common and changed the class in Gateway to implement that interface. As Gateway depends on Common, this is bearable. I then wired the class in Gateway into where it was needed in Common at runtime with spring using the newly created interface.

Works a treat.

Jackson Custom Deserializer Example – Annotated MixIn

Having  just recently started using Jackson I ran into the issue of a serialising a old-style static enum pattern class. This class has no constructor (all “enum” options are static instances) so I had to make my own deserialiser.

There are two ways to map the custom deserialiser – via a Mixin or via a factory.

Mix in:

Create a MixIn for the Class that contains the Enum – overriding the field or setter

public abstract class JacksonMyStaticEnumMixIn {

  JacksonMyStaticEnumMixIn() { }

  @JsonDeserialize(using=MyStaticEnumDeserializer.class)
  public MyStaticEnum myStaticEnum;
}

Then add this to the object mapper:

ObjectMapper mapper = new ObjectMapper();
// Implicit deserialisation mapping via mix in class
mapper.getDeserializationConfig().addMixInAnnotations( ClassContainingStaticEnum.class, JacksonMyStaticEnumMixIn.class);

Explicit Binding:

The mix-in method can not be checked by the compiler and requires discovery, rather than being intuitive. The other option is an explicit binding via a factory as follows:

ObjectMapper mapper = new ObjectMapper();
CustomDeserializerFactory factory = new CustomDeserializerFactory();
factory.addSpecificMapping(MyStaticEnum.class, new MyStaticEnumDeserializer());
mapper.setDeserializerProvider(new StdDeserializerProvider(factory));