Almost every application needs to handle data in an interchangeable format. In the world of http JSON based API’s, the task of serializing and deserializing the payloads are something usually delegated to a third party library. Some examples are Jackson, Gson and the most recent Java EE spec JsonP. What if there is a way where applications can be decoupled from these providers in a similar fashion of how SLF4J does for logging? That’s the goal of Payload.

<dependency>
  <groupId>com.juliaaano</groupId>
  <artifactId>payload</artifactId>
  <version>${check.latest}</version>
</dependency>

// Serialization
Payload<MyObject> payload = 
	JSON.payload().newInstance(new MyObject());
String json = payload.raw();

// Deserialization
Payload<MyObject> payload =
	XML.payload().newInstance(xmlAsString, MyObject.class);
MyObject obj = payload.get();

Payload acts as a facade for the various libraries out there, which means it needs to find in the classpath a third party to do the actual work. Just like SLF4J would need log4J or Logback, for example.

The design is quite flexible in the way it can accommodate custom implementations of the mechanism that does the conversion. I call it the Provider in this context. Understand more about providers in https://github.com/juliaaano/payload#providers.

Testing is something that you might want to use this library for. The ability to swap the underlying provider gives you a way to assemble your JSON test data using a different instrument rather than the one used production, but still keeping the same API.

No major performance drawbacks have been identified by using Payload instead of directly employing Jackson or Gson. The project contains a few JUnit benchmark tests to address the matter.

I have created a small app as a proof of concept for this project: Payload Tests. There you can see how things are expected to work, including the implementation of a custom provider.

Great effort has been put in the design aspect. It is fair to mention the main motivation behind this initiative was actually to exercise good practices such as object composition, OOP, build a pipeline to continuously release in Maven Central, just to name a few. If you have read this far and have also found value in what has been built, I’d be more than happy to accept your contributions. Keep the good coding.