Add JSON-B Support / Make Jackson optional

[tandraschko]

Checklist

• I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• I have taken the time to fill in all the required details. I understand that the feature request will be dismissed otherwise.
• This issue contains only one feature request/enhancement.

Description

There are environments where JSON-B is available, but the chartjs model depends on Jackson.

Would be possible to support both? Like define both Jackson/Json-B annotations in the model and let the user decide which one to use for serialization.

Additional information

No response

[AB-xdev]

Thank you for the issue.

I'm not sure about this one:
Currently annotations are used in certain places. If another library is added other annotations are additionally needed.
A user might be able to exclude a library (e.g. jackson) however they will not be able to remove these annotations which will result in a crash due to a linking failure.

So as far as I can see this would mean that we effectively would have to maintain 2 models: One for Jackson and one for JSON-B.
Supporting 2 JSON libraries at least doubles the maintenance effort and I don't think that's sustainable.

Additionally there's the problem with JakartaEE "standards"/application servers...

1. There is no real standard. We had a lot of problems in the past how "standards" are differently implemented across application servers (e.g. JPA lazy querying behavior).
2. Sometimes there is stuff missing in the standard (e.g. Same Site cookies in the past)

So if we now specify stuff in JSON-B it might work on appserver A while there is a slightly different behavior on appserver B which screws us over. That's additional maintenance effort that we would have to cover.

---

I also had a look at the original issue and I don't quite understand Wildfly's problem here.

https://docs.jboss.org/resteasy/docs/3.6.0.Final/userguide/html_single/index.html#d4e512

WildFly 14 supports specifying the default value for the resteasy.preferJacksonOverJsonB context property by setting a system property with the same name. Moreover, if no value is set for the context and system properties, it scans JAX-RS deployments for Jackson annotations and sets the property to true if any of those annotations is found.

Uhm just because Jackson Databind is on the classpath nobody forces Wildfly to use it for everything 😆

So I think explicitly setting resteasy.preferJacksonOverJsonB to false should be enough.

Also:
Application servers should nowadays be effectively extinct and have been largely eradicated by containerized deployments. ¹²

So I think there is currently not really a point in investing time here.

Footnotes

1. https://www.jetbrains.com/lp/devecosystem-2023/java/#java_web_frameworks ↩

2. https://www.jetbrains.com/lp/devecosystem-2023/java/#java_app_server ↩

[tandraschko]

If the annotations have the right retentionspolicy, the classes can just have both Jackson and EE annotations.

So we just need a few tests, if the serialization output is the same.
If this works, you dont need jackson in a EE Container.

[AB-xdev]

If the annotations have the right retentionspolicy

Not sure what is exactly meant by this but AFAIK the retention policy is always Runtime as the Annotations are needed at runtime.

[tandraschko]

what i actually meant is, that this makes no problem when either jackson or jsonb is not available:

	@JsonIgnore
	@JsonbTransient
	Map<String, Object> scalesList = new LinkedHashMap<>();

but there are a few harder dependencies like:

@JsonSerialize(using = JavaScriptFunction.Serializer.class)
public class JavaScriptFunction
{
	private final String function;
	
	public JavaScriptFunction(final String function)
	{
		this.function = function;
	}
	
	public String getFunction()
	{
		return this.function;
	}
	
	public static class Serializer extends JsonSerializer<JavaScriptFunction>
	{
		@Override
		public void serialize(
			final JavaScriptFunction value,
			final JsonGenerator gen,
			final SerializerProvider serializers) throws IOException
		{
			gen.writeRawValue(value.function);
		}
	}
}

i think both jackson and jsonb would allow to have the serializater (or converter how its called in jsonb) in a external place like a own module: chartjs-java-model-serializer-jackson / chartjs-java-model-serializer-jsonb

but not sure if its worth