Use of JSON-LD module in RDF4J 5.0: JsonProvider implementation on classpath via SPI

[aschwarte10]

Hi,

we are currently doing more extensive tests of RDF4J 5.0 and have a question to the JSON-LD module, specifically rdf4j-rio-jsonld.

When using this, it requires the following dependencies:

• no.hasmac:hasmac-json-ld
• jakarta.json:jakarta.json-api
• org.glassfish:jakarta.json

With this classpath it looks like there is no implementation of JsonProvider automatically detected, e.g. via SPI. It looks like the implementation falls back to the implementation of org.eclipse.parsson:parsson (which at least on the json-ld module is not on the RDF4J classpath).

We found that the glassfish binary provides an implementation, which is not registerd using SPI though.

How is this meant to work generally in RDF4J?

Note: in our case we simply registered the implementation of JsonProvider from glassfish manually using SPI on our classpath.

[hmottestad]

It uses the following code in hasmac-json-ld to retrieve the implementation:

https://github.com/HASMAC-AS/hasmac-json-ld/blob/b6ab827821cc5f915854346fd3b7338c6a7f17e1/src/main/java/no/hasmac/jsonld/json/JsonProvider.java#L27

When I put a break point in this and print the full class name it shows the glassfish implementation.

[hmottestad]

It's falling back on the default implementation which is glassfish in that case. If you are getting Parsson then it might be related to Elasticsearch.

I'll add the service file to register the glassfish implementation.

Hasmac-json-ld is a fork of Titanium JSON-LD with a bunch of performance improvements and integration improvements to let it work better with RDF4J. The author of Titanium JSON-LD went with Jakarta JSON API because they wanted it to be up to the users to select their own implementation. From what I gather Jakarta JSON API is all but dead and it's also one of the slowest solutions. If it wasn't for the tight integration between Titanium JSON-LD and Jakarta JSON API I would have switched to Jackson.