Make Jackson waterproof and avoid it failing in native image

[hohwille]

Task summary

Issue #1644 was again one of many issues where we implemented some feature using Jackson to deserialize JSON to Java and all was green in Java but failed in GraalVM native image.
My initial plan was to find a way to disable (deep) reflection support in Jackson somehow entirely and force ourselves to always write JsonDeserializers already to make it work in Java.
However, @maybeec had a great idea that seems even better:
In PR #1655 he wrote a JUnit test that tries to find all classes that we deserialize from JSON and checks that they are all listed in reflect-config.json. Currently this test only finds classes that implement JsonObject or JsonVersionItem.
The problem is that there are many other classes affected not found by this condition:

• Cve
• ToolSecurity
• ToolDependency
• VersionRange
• VersionIdentifier
• CustomToolsJson
• CustomToolJson

Side note: JsonVersionItem is not used by IDEasy itself but only by our UrlUpdaters that always run in JVM.
But since these classes are not inside the cli module, the test would not find them anyhow so it does not harm.
Since JsonObject is only a marker interface, we should derive JsonVersionItem from JsonObject.

My ideas on this:

• We already have JsonMapping to somehow centralize and wrap our Jackson configuration.
• We could even wrap Jackson entirely creating our own API to deserialize JSON that only accepts Class<? extends JsonObject>.
• BTW: Do we need to create separate instances of ObjectMapper or can we share a singleton instance? IMHO it is not stateful and therefore we could simply do that. Then we could even simplify our own code with the "wrapper".
• Our test can then find at least all root objects that must implement JsonObject.
• We could find all child objects via refelection by decomposing the root objects.

If that approach turns out way too complex, we could still try to find out if we can disable the generic reflection based deserializer in Jackson what should IMHO be possible or we raise a feature request for that.

Additional context

No response

[hohwille]

Input for the fallback solution:
ObjectMapper has a constructor with 3 args taking DefaultDeserializationContext as the 3rd argument.
By default all 3 args are passed as null.
This makes it using new DefaultDeserializationContext.Impl(BeanDeserializerFactory.instance) as default.
That is exactly what provides the reflective deserialization support.
We can therefore disable that and make Jackson to only deserialize standard types and what we have registered as custom deserializer.
In case we would have to stay with the crappy current boilder-plate approach, we could easily enforce this and make all JUnits fail in JVM if we missed to register an according JsonDeserializer. This way we would fail in JUnits already instead of passing and failing only in native image.

[maybeec]

There are pretty interesting options on auto-generating custom serializer bytecode at compile time to prevent this issue:
https://quarkus.io/blog/quarkus-metaprogramming/
Could be also promising, but might be further investigated