JSLT without Jackson

The current JSLT implementation is so tightly bound to Jackson that every value is a Jackson JsonNode, but there are users who want to use JSLT without Jackson. There is an experimental branch with a custom JSLT VM which could be developed further to provide a Jackson-less JSLT.

There are three main challenges here:

• Functions: these have to be reimplemented. Or one might have a core layer based on pure Java types, which the VM and the existing implementation both translate to.
• Input representation: how is the JSON data passed to JSLT in this case?
• Output representation: how is the JSON result returned?

All of these problems can be solved, but it would be good to get some input on to what extent there are people out there who need a JSLT with zero runtime dependencies. And also what requirements these people have for the input/output representation.

Input wanted!

[mrange]

Hi Lars.

We (Schibsted Pulse) are one of the users that would value a JSLT with no dependencies. Without boring everyone with the details I just mention that we run into conflicts between Spark which has a dependency on Jackson and JSLT that has a dependency on Jackson of a different version.

Below are some thoughts around the problem but I don’t claim they are well-thought out.

As the JsonNode is exposed in the API using shadowjar to pull in jackson into the jar and rename the namespace don’t seem feasable.

An idea I have been toying with is that JSLT provides it’s own writable JSON DOM (perhaps functionally identical to Jackson in all ways that matters to JSLT?).

As a convenience to the users there could be a JSLT.Jackson module that most users depend upon that implement JSON => JSLT JSON DOM => JSON transformations.

That way the core JSLT could have no dependencies and users like us that have specific runtime demands have the possiblilty to implement JSON => JSLT JSON DOM => JSON on a specific version on Jackson or using a different parser all together.

Important is that the API still have to be perceived as convenient to use so our maybe specialized needs don’t reduce usability for the normal user. As we might be the odd guys here I would be ok with a slightly less convenient API for us as long as we can exclude Jackson and provide our own parsing.

Another option is to provide several version of JSLT with different Jackson version but I am not a fan of that having to provide several versions of an internal library for different versions of scala.

Regards,

Mårten

[lukaszgendek]

In my project we use kotlinx serialization library which brings it’s own JSON representation - different than Jackson. a Jackson-less JSLT would be really valuable.