Split project depending on API used

[lordofthejars]

Currently project is only one project which depends on Jackson. Next version of Java EE (Java EE 8), will contain JsonPointers inside Json Processing API. For this reason I think that it would be great to split the project into different modules depending on underlying platform.

What I suggest is something like:

A module called core or api which will contain the common classes and interfaces to abstract from JsonPointer implementation.

Then a module for each implementation. For example we can have a jackson implementation or jsonp (the Java EE 8 ones) implementation. And of course everyone will be able to collaborate with their own library. Let's say for example a RestEasy implementation as well.

Of course this is not something to be done just now, but we can start a discussion and have it in mind.

[fge]

I was kind of thinking about it... Other projects I have have the same constraints.

By the way, I suppose you are referring to javax.json?

While I kind of like the idea, there is the problem that it can be heavy -- either implementation wise or runtime wise.

Basically, there are two solutions:

• deciding on a library to use at the core; write conversions from other JSON representations to the core JSON representation (for instance, from Gson's JsonElement to Jackson's JsonNode and back);
• implementing the same functionality for all libraries -- ouch.

In fact I quite like the idea of javax.json; at least, unlike JsonNode, JsonValue is immutable! I have bugged Tatu so that JsonNode also be immutable but he never wanted to. As a result, well, with some malicious code none of the libraries are used are totally thread safe, and I overuse JsonNode's .deepCopy()...

[daveclayton]

Hi @lordofthejars is this something that you'd still find useful?

Let's discuss.